A Comprehensive Look at How to Harden Your eCommerce Solution Security Defenses with the Help of HTTP Security Headers
Greetings, weary eCommerce merchant. You know very well by now that there are a vast number of elements to consider when you’re in the process of implementing security measures into your web application or website. Your eCommerce solution should be a shining bastion amongst the dark alleyways of the web, a citadel with sentries keeping watch day and night. Consider your HTTP security headers as these very sentries - they are easy to implement, and require only a slight web server configuration change.
A subset of HTTP headers, HTTP security headers are swapped between a browser and a server to define the security parameters of HTTP communication. These wardens of the web provide an additional layer of security by helping to curb common attacks such as cross-site scripting (XSS) and clickjacking (more on that later). Implementing security headers conveys that you are keeping up with best practice in the information security industry, because they are still largely considered the best way to secure your web application, according to OWASP and SANS recommendations. As an added bonus, it discourages bad actors from attempting to break into your web application.
Still, bear in mind that solely implementing security headers will not magically solve all of your security issues. As with any security mechanism, it does not provide a 100% efficacy rate of protection against online attacks. The aim is simply to reduce the likelihood of attacks, and mitigate the attacks.
Let's Get Started
We will focus on the following security headers in this article:
HTTP Strict Transport Security
We’re looking at these security headers specifically because they are currently the most commonly used, and the majority of them are quite easy to implement. Our goal is to convey the best practice when it comes to security headers, including the appropriate usage and implementation.
We will not cover rarely used, almost deprecated, and already deprecated security headers because most modern browsers no longer support them. However, please note that the usage of old and deprecated headers, as well as outdated software, may very well attract bad actors to your website. If an attacker spots old software or deprecated technology on your web application, they may just take a closer look; an online criminal knows that they may have an increased possibility of discovering a vulnerability they can exploit within aged technology. That’s why conducting regular platform and security hardening is extremely important to the safety of your web application.
We recommend the OWASP Security Headers Project website for a deeper dive into rare and deprecated headers. It offers numerous interesting examples relating to all security headers with useful case studies.
On that note, let’s take our security headers one by one for a closer look.
HTTP Strict Transport Security (HSTS)
HSTS is a web security policy mechanism that helps protect websites against protocol downgrade attacks and cookie hijacking. In general, it allows the server to force browsers to only communicate via a secure channel, and never via an insecure HTTP protocol.
For example, you may install a SSL/TLS certificate onto your website, and migrate your website from HTTP to HTTPS (incidentally, this is a fantastic thing to do in the 21st century). However, your website may still be available via HTTP, if after the website was migrated to HTTPS, the HTTP vulnerability remained. This is where HSTS enters the scene. If a website is equipped with HSTS, the server forces the browsers to communicate over a secure channel exclusively; this way, there’s no way to establish a connection to your server via HTTP.
HSTS features three directives; the first of them is max age. It’s the time in seconds that a browser should remember that your site is accessible only via HTTPS. The second directive includes the subdomains. This is not a required directive; however, in case this directive is specified, the rule will apply to all the site’s subdomains.
The third directive is preload, and it’s not a part of a specification. Google maintains this HSTS preload service, and as a result of successfully submitting your domain to this service, browsers will never connect to your domain using an insecure connection.
Currently, almost all major browsers use the preload directive; however, it’s not part of the HSTS specification, and it should not be treated as official for now. Incidentally, submitting your domain to this preload service presents its own set of challenges.
Currently, we recommend using the second directive, which sets the max age to one year and includes all of the subdomains.
X-Frame-Options improves the protection against clickjacking by telling the browser whether the contents of your web application can be displayed within frames on other domains or web applications.
First, we must clarify the concept of clickjacking. For instance, a website may display a button that invites a user to donate one dollar to charity by clicking on it. A bad actor may have loaded a transparent iframe containing a link to his own bank details over that button, meaning when the target tries to donate one dollar to charity through a visually harmless UI element, they will instead click on an invisible “confirm transfer” button. This way, the bad actor has hijacked the user’s click, and the money will instead be transferred to the thief’s account details.
The best practice for X-Frame-Options is always “deny.” Essentially, you must try to avoid a situation where a frame would be needed on your website. If you need to use a frame on your website or web application, we recommend using the SAMEORIGIN directive. A bad actor can bypass this directive by modifying the origin request header; if you must frame your web application on a particular domain use the ALLOW-FROM directive where you can specify the URL in which your web app can be framed. While it’s possible to find a way to bypass the ALLOW-FROM directive as well, it’s a trickier endeavour that not many individuals are familiar with and it provides a measure of protection against clickjacking.
This is where MIME sniffing enters the scene.
In general, MIME sniffing may be broadly defined as a practice adopted by a browser to determine the effective MIME type of web resource by directly examining the content of the resource, instead of relying on the Content-Type header.
MIME sniffing may vary by browsers, and can only be performed under specific conditions. To avoid issues with MIME sniffing, we recommend a properly set up Content-Type header; even better, utilize X-Content-Type-Options to curb sniffing entirely. This header only has one directive, and it will always be “nosniff.”
HTTPS requests may include the optional referrer header, which indicates the origin of the web URL from which the request came from. The Referrer Policy defines what data is made available in the referrer header; sometimes, the referrer header may be very insightful. For example, an analytics service might use this header to determine that 60% of visitors to a website came from a specific social network.
However, when the full URL is sent in the referrer header across origins, this may pose a security risk as well as reveal private data. The URLs may contain private information such as health care data, private user emails, passwords, tokens, and more. All of this data can be leaked via the referrer header. In order to restrict what referrer data is made available for request from your website, it’s advised to set up a Referrer Policy.
A Referrer Policy contains eight directives. The first directive is the best from a security standpoint, because the Referrer-Policy: no-referrer ensures that absolutely nothing will be transferred via Referrer Policy. If there’s no data being transferred, there’s no chance of a data leak!
The next one is the no-referrer-when-downgrade, which sends all data, including the origin, path, and query string only when the protocol security level is the same, or higher. For example, from HTTP to HTTP, HTTP to HTTPS, and HTTPS to HTTPS. This directive ensures that no referrer headers are sent to requests coming to less secure destinations.
Our next directive, the referrer-policy: origin, only sends the origin in the referrer header. For example, it will only send the URL without query strings. It sends the origin to different level protocols.
The fourth directive is Referrer-Policy: origin-when-cross-origin. This directive will send all data when performing a same-origin request to the same protocol level. Send the origin (only) for cross origin requests and requests to less secure destinations.
The fifth directive, Referrer-Policy: same-origin sends the origin, path, and query in the referrer for same-origin requests; but no referrer information is sent in the case of cross-origin requests.
The sixth directive, Referrer-Policy: strict-origin, only sends the origin when the protocol security level stays the same; for example, from HTTPS to HTTPS. No Referrer information is sent when requests come to less secure destinations, such as from HTTPS to HTTP.
The seventh directive, Referrer-Policy: strict-origin-when-cross-origin is the default policy for all major browsers if no policy is specified. In this case, origin, path, and query is provided upon same-origin requests. Only origin is provided when the protocol security level stays the same, such as from HTTPS to HTTPS. No Referrer information is provided to requests from less secure destinations, such as from HTTPS to HTTP.
The final and most insecure directive, Referrer-Policy: unsafe url, designates that the origin, path, and query string is provided in any case, meaning all information is sent to any request. This is the most insecure Referrer Policy, because all information is sent in any case.
Let's Wrap This Up
To recap, we have discussed four security headers, and the most secure approaches for each of them:
Strict-Transport-Security: max-age=31536000 (for one year); includesSubDomains
From a security perspective, these are the most secure configurations for each of the security headers, because they all deny insecure behavior and do not allow data leakage. From a business perspective, you may want to modify the Referrer Policy, but remember, utilizing an unsafe URL directive in Referrer Policy is considered exceedingly bad practice. We also advise against modifying the other security header settings.
To stay current with security headers in your eCommerce project, head over to Security Headers, a quick tool that encompasses all the current best practices on this topic.