Securing a website: risks, challenges and best practices

The security of websites (e-commerce websites, corporate websites, SaaS platforms and other web applications) is a major issue for companies. Being exposed to the public, these systems are naturally prime targets for attackers, who take advantage of numerous vulnerabilities in the features and other components: servers, data, third-party components, and other critical features such as authentication, session management or access control.

Why is it important to secure a website?

Beyond the protection against malicious intrusions, security is also a major selling point and a key aspect to reassure and therefore turn prospects into customers. Indeed, during discussions with a prospect for the subscription to a SaaS platform, for example, it is not uncommon for the question of cybersecurity procedures and actions carried out by the publisher to arise. Thus, a certification (SOC or ISO 27001), a security audit certificate or a penetration test report can help overcome this type of barrier. In the same way, an e-commerce platform that features a third-party security seal will be more likely to convert visitors and reduce cart abandonment.

Securing a website is therefore vital and necessarily requires the implementation of best practices in terms of development, integration, monitoring, and security testing. This article is not intended to be exhaustive. It will address web security only from the perspective of best practices, with some additional information on the risks, types of attacks and vulnerabilities that can be exploited by attackers to compromise a website. We therefore invite you to consult our article: How to strengthen the security of web applications to counter the most common attacks? in order to have a more global vision of the security issues and risks related to websites (web applications, e-commerce sites, SaaS platforms, etc.).  

Control your exposure and reduce your attack surface 

Let’s get to the heart of the matter with an essential aspect, which will also be the main thread and overall summary of our article: the exposure of a company, in other words its attack surface.

The question of the attack surface is central to a cybersecurity approach because it is at the heart of the attackers’ strategy. Indeed, any computer attack on a website, an internal network or an external infrastructure generally begins with a reconnaissance phase, enabling potential entry points to be identified. Furthermore, it should be noted that hackers very rarely target a specific company or a specific website. They look for potential targets all over the place. And their favourite victims are the most publicly exposed companies, with the largest attack surface.

The attack surface may concern a website or any other software, a network, it can be human or physical.

And a company’s attack surface will ultimately be made up of all these elements.

  • Administration services (SSH, FTP, MySQL, etc.) exposed publicly.
  • Debug modes enabled on a production environment.
  • A demo platform, accessible online or downloadable, that is a carbon copy of your production web application.
  • A popular plugin used on WordPress that has not been updated with known vulnerabilities in previous versions.
  • Accessible architecture documents.
  • Default credentials on an exposed service or machine to access the administration interface.
  • An unsegmented internal network with a guest WI-FI allowing eavesdropping.
  • Data leaks containing unrevoked credentials of a former employee.

All these examples are breaches that, if properly exploited, can allow attackers to compromise an information system. And these scenarios are real. They are indeed cases encountered during reconnaissance phases – the first step in the methodology of any penetration test – within the framework of website, e-commerce platforms, web applications penetration tests, internal network pentesting, etc. or during reconnaissance audits carried out by the ethical hackers that we are.

How to map your attack surface?

To reduce its attack surface, it is first necessary to draw up a precise and complete map. This means listing all the assets, their versions, and linkages throughout your IS. Tools such as censys or shodan facilitate this process.

In this way, you can map the attack surface of a specific machine or web application. For a web application, this will involve listing all dynamic web pages, forms, open ports, system accounts, all running applications or services (APIs for example), etc.

Following this mapping, which must be exhaustive and continually updated because systems are never static, a detailed analysis of all the elements identified must be carried out. For an open port, for example, we can look for anything that could be used by an attacker to take advantage of the exposure of this port. For an application, starting with a standard user account, we can test the possibilities of privilege escalation, etc.

The results of this analysis will make it possible to identify the most critical points in order to apply the necessary hardening measures.

How to reduce your attack surface? 

The following are examples of system hardening measures that help reduce your attack surface:

  • Limit access to administration modules by applying IP restrictions.
  • Remove test, debug, and obsolete code from production applications.
  • If possible, use static content in application demos.
  • Remove sample code and programs from production servers and your applications.
  • Avoid or carefully control third-party components.
  • Apply the principle of least privilege in managing access rights to servers, applications, databases, etc.
  • Segment the network and isolate critical systems and applications.
  • Change the default passwords for all your connected services and devices.
  • Uninstall or remove unused applications, services, and environments.
  • Keep a technical and technological watch on new releases and vulnerabilities discovered in third-party components or services used.
  • Revoke the credentials of your former employees.

Securing web servers 

Web servers, because of the sensitive data they host, are one of the most targeted elements by attackers. Server security is therefore just as important as the security of the application layer.

Below are the security measures and best practices to implement to secure a web server. For security risks related to the cloud, you can consult our dedicated article on this subject: Cloud security: what are the risks and best practices?

Remove unnecessary services

In a default installation of an operating system and a server, many unnecessary services and modules are installed. However, the more services there are, the more ports will be open, leaving large gaps that can be exploited by external attackers or malicious users. Disabling unnecessary services will not only free up hardware resources but will also make your server more efficient and secure.

Indeed, it is important to configure your server based on only those services that are essential to your business, assuming that everything that does not need to be authorised should be prohibited, everything that is unnecessary should be disabled or removed, to avoid unnecessary and potentially dangerous access points.

Apply the principle of security through obscurity

  • Minimise the information delivered by the services and in the source code of your website.
  • Customise all error pages in such a way as to not disclose any information that could help an attacker.
  • Remove traces and configure the server so as not to disclose the technologies and versions used.
  • Rewrite URLs to hide the technologies used.
  • Disable the display of directory contents.

Separate development, testing and production environments

For ease of use, it is common for web application development and testing to be carried out directly on the production server. This practice should be avoided as these applications usually contain vulnerabilities, which can easily be discovered and exploited by a malicious user.

Ideally, web application development and testing should always be performed on servers isolated from the Internet and should never use or connect to real databases to reduce the risk of bounce attacks.

Securing authentication, session management and access control of a website

The most targeted features on a website by attackers are undoubtedly the authentication, session management system and access control. Brute force, session theft, privilege escalation, etc., the possibilities of attacks are numerous, but the means of defence are just as numerous.

We have published an article dedicated to best practices for securing the authentication, session management and access control systems of web applications

Protecting sensitive data

In many web applications, sensitive data such as credentials and authentication information are not properly protected. This sensitive data must be encrypted when it is at rest or in transit. In general, the following precautions should be taken:

To protect data at rest

  • Store sensitive data (user passwords, banking information, etc.) with a robust, iterative, and salient hash function. Indeed, user passwords should never be stored in clear text. They should be stored using secure key derivation hashing techniques such as the bcrypt algorithm. For more information, we refer you to our article: How to securely store passwords in database?
  • Implement secure processes for managing secrets and certificates.

To secure data exchanges

  • Use the TLS protocol to encrypt communications between a client and a server. This enables to secure the content of exchanges during a Man in the Middle attack for example.
  • Disable the unencrypted version of all protocols for all TLS enabled resources.
  • Implement the HSTS (HTTP Strict Transport Security) header on your web server to force a browser to use HTTPS secure connections.
  • Securely exchange encryption keys.
  • Use TLS certificates validated by a trusted and recognised certification authority.
  • Use certificate pinning to add another layer of security. Certificate pinning is an additional method of validating the server certificate. In addition to performing the usual checks on the certificate presented by the server, such as validating the certification chain to a root certificate or its validity date, the application also checks certain characteristics of the certificate, such as its serial number and the public key associated with it. The advantage of this method is that it is more robust than the traditional method and does not rely solely on the root certification system or authorities to ensure that the certificate presented is the correct one. For more information on this method, you can consult our dedicated article: Certificate and Public Key Pinning.

Security of third-party components

Most websites and web applications use third-party components: libraries, frameworks, etc. These components help developers to reduce the time needed between the design phase and production deployment. However, they can represent a significant security risk, with the possibility of various vulnerabilities: injections, XSS, misconfiguration, etc.

We have described the security issues related to the use of third-party components in our article on common web application vulnerabilities and attacks. You can refer to that article for third-party component security, as well as for other aspects such as logical flaws in web applications.

Perform a penetration test to assess the security of your website

Websites and applications are particularly attractive targets for attackers, due to their exposure and the many vulnerabilities that can be exploited more or less easily. This is why it is important to assess the robustness of your website against real attacks. This is the objective of a penetration test (pentest).

A penetration test consists of the analysis of a computer system, a network, or a web application to find security flaws that an attacker could exploit and to recommend security fixes. During a website penetration test, the aim is to look for vulnerabilities both on the server side (open and poorly secured services, out-of-date software, configuration errors, etc.) and on the application layer (injections, XSS, authentication and session management violations, exposure of sensitive data, etc.), with 3 possible approaches: black box, grey box or white box tests.

  • In black box testing, tests are carried out without any specific information about the target system. This is the closest scenario to a real external attack.
  • In a grey box penetration test, the pentesters perform the tests with partial information about the target system. This could be user accounts in order to search for vulnerabilities by putting themselves in the shoes of an authenticated user.
  • In a white box scenario, the pentesters have a maximum of information on the target system, in particular admin access accounts and the source code if it is a web application. In fact, this is the most exhaustive approach to identify flaws and propose security fixes.

Regardless of the approach taken or the scope of the tests, a complete report is produced following any penetration test. It includes the methodology followed, the vulnerabilities identified, the level of criticality, the possible exploitation, and recommendations for correction. The penetration test may be completed by a validation phase of the corrections to verify their correct implementation and the absence of side effects.