Beginner’s Guide to Security Headers
Part 2: Common types of Security Headers and how to implement them
Welcome to Part 2 of our Beginner’s Guide to Security Headers. In Part 1, we covered the basics of security headers and why they’re important for protecting your website from common cyber threats. In this second part, we’ll dive deeper into the most common types of security headers and how to implement them properly. You’ll learn about HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), X-Frame-Options and other essential headers that can help secure your website. By the end of this article, you’ll have a better understanding of how these headers work and how to add them to your website to enhance its security.
What are the different types of security headers?
If you have worked with security headers in the past, or while reading this article, you will notice that some security headers start with an X and some don’t. This is because in the past, developers used the “X-” prefix to mark non-standard headers. The “X” stood for “experimental” or “extension”.
However, this caused a problem because non-standard headers sometimes got mixed up with standard headers or became standard later on, which caused issues when transitioning from the non-standard to standard name. This also created problems for older and newer implementations, which may not support the same naming conventions.
To avoid these problems, newer implementations often continue to support the “X-” prefix, which means that it has become a de facto standard. Therefore, the separation between standard and non-standard naming areas is no longer necessary.
Source: https://datatracker.ietf.org/doc/html/rfc6648
The most used security headers are as follows:
- Strict-Transport-Security (HSTS)
- Content-Security-Policy (CSP)
- X-Frame-Options
- Referrer-Policy
- X-Content-Type-Options
- Permissions-Policy
A great tool to check the security of websites and applications is https://securityheaders.com. An example of a good scoring website is the BusinessBike Sweden website (https://securityheaders.com/?q=businessbike.se&hide=on&followRedirects=on):
Strict-Transport-Security (HSTS)
The Strict Transport Security header forces the browser to communicate with HTTPS instead of HTTP, preventing most man-in-the-middle attacks. Based on the current security insights this header must be present on all pages of the website or -app, but pay attention to the note at the end of this chapter.
As mentioned earlier in this article, if the browser of a user previously accessed the website and received this header, it will refuse to connect over HTTP even when the user explicitly clicked on or typed in a link starting with `http://`.
An example of a HSTS headers is as follows:
Strict-Transport-Security: max-age=31536000; includeSubDomains
In this example, the max-age option denotes the number of seconds the browser should remember this setting, and we’d like it to apply it to all subdomains as well, hence the second option.
There are situations where you should avoid using HSTS, for example if you are deploying a new website and still testing the HTTPS configuration. If you enable HSTS, users will be forced to access the HTTPS version of your website, even if there are issues with the certificate or configuration, which can cause security warnings and issues for users.
Additionally, you should avoid using HSTS if your website has a large number of subdomains, especially if those subdomains are hosted by different entities. HSTS policies are domain-specific and cannot be set for individual subdomains, which can cause issues with cross-domain security and certificate validation.
Content-Security-Policy (CSP)
The Content-Security-Policy header controls from which origin(s) the browser is allowed to load data from. By default, browsers will load any content from any source, which can allow attackers to inject malicious scripts into a website. The Content-Security-Policy header enables website owners and developers to whitelist trusted sources of content, such as their own domains or CDNs, and prevent any other sources from loading content. Implementing this header will also restrict which domains are allowed to be contacted by scripts added to the website.
This header contains many directives, such as default-src, object-src, img-src and more. The most common one used is script-src, which defines where scripts can be loaded from.
Using third-party integrations, like Google Tag Manager or embedding videos from YouTube would require all different origins to be listed, making it a quite substantial header. An example can be found on businessbike.se:
X-Frame-Options
The X-Frame-Options header can be used to prevent clickjacking attacks by embedding the website in an iFrame on a (external) domain. With this header in place you can allow only certain origins to embed your website or -app in an iFrame, allow only the same origin or block embedding completely.
X-Frame-Options: DENY (Page cannot be framed)X-Frame-Options: SAMEORIGIN (Allow framing from pages of the same origin: same protocol, host, and port)X-Frame-Options: ALLOW-FROM https://google.com (Allow framing from specified domain)
Please note that using iFrames to display content on a website might not always be the best approach because they can introduce (servere) security risks and possibly could have a negative impact on the user experience when using the website.
From a security perspective, iFrames can make it easy for attackers to inject malicious code into an iFrame and potentially utilise it to steal sensitive information, such as login credentials or personal data, from the website visitor. Therefor iFrames should only be used when there is no suitable alternative but should be omitted if there are any other ways present.
Referrer-Policy
The Referrer-Policy header will mostly contain the address of the previous web page from which a link to the currently requested page was followed. This can cause information to leak away (when the request originated from a private website or -app, such as the intranet, or even your mailbox). There are many different options for this header to choose from, the most used ones are no-referrer, origin, origin-when-cross-origin, and same-origin.
no-referrer will never send the referrer to the destination.origin sends only the origin of the referrer, not the path or parameters.origin-when-cross-origin sends only the origin when the destination is another origin, and otherwise it sends the whole referrer.same-origin will only send the whole referrer when the destination is of the same origin.
X-Content-Type-Options
This header prevents MIME-sniffing. MIME-sniffing happens when browsers try to determine the requested file type by examining the content, regardless of the Content-Type header. Doing so can lead to vulnerabilities, an attacker can upload a JavaScript file with the extension of an image file. When trying to view the image, the browser detects that the file is a JavaScript file and executes it instead of showing it as an image. Setting this header to nosniff will prevent MIME-sniffing.
X-Content-Type-Options: nosniff
To make the most use of this header, it should be present for all resources.
Permissions-Policy
The Permissions-Policy header lets you enable and disable browser features. For example, you can control whether the current page and any embedded pages have access to the user’s camera, microphone, and speaker for example. This can be set for each individual feature, from disallowing usage completely, only enable it for (embedded) pages of the same origin or enable it for all (embedded) pages.
There are several situations in which the Permissions-Policy header may be useful. For example, if a website uses external/third-party content, it may be necessary to limit access to certain features or APIs to prevent malicious content from accessing sensitive user data. Additionally, if a website relies on certain features or APIs that may be vulnerable to attack, such as geolocation or microphone access, it may be necessary to limit access to these features to prevent potential security breaches.
That concludes Part 2 of our Beginner’s Guide to Security Headers. We hope this article has provided you with a better understanding of the most common types of security headers and how to implement them properly. By implementing these headers, you can greatly enhance your website’s security and protect your visitors from common cyber threats. In Part 3 of this series, we’ll cover advanced techniques for implementing security headers and best practices for maintaining a secure website. Stay tuned to learn more!
