6 security headers that you should be using on your website

Let's talk about security headers! A security header is an additional instruction that the web server sends to the web browser in response to a request, along with the content body of the response. This instruction gives the browser precise directives on how to handle the page content, in order to improve the website's security.

Security headers play a crucial role in protecting websites against a variety of attacks or data leaks, including for example :

• XSS (Cross-Site Scripting): injection of malicious code into a web page to steal data or hijack user actions ;
• Clickjacking: a phishing technique in which a clickable element is hidden beneath another element in order to induce the user to perform an undesired action ;
• Code injection: introducing malicious code into an application to modify its behavior.

The Referrer-Policy header

Referrer-policy is a header that is still under-used, even though it protects user privacy by limiting the amount of referrer information that is sent with HTTP requests. This can help prevent the leakage of more or less sensitive data, such as the URLs of pages visited.

Why is it important? When the visitor of a website clicks on a link, a request header Referer is sent along with the request, and it contains the URL of the page that the visitor comes from. Hence, the destination website can know precisely the URL of the web page the user comes from, which can provide some personal information.

This information, traditionally sent in the Referer header, reveals the origin of a request, potentially exposing sensitive user data.

To mitigate this privacy concern, the Referrer Policy allows website owners to restrict the level of detail shared. By setting this header, you can specify whether to send no referrer information, only the origin (domain and path), or the full URL.

Here is an example of the Referrer-Policy header syntax:

Referrer-Policy: no-referrer

See it? It's pretty straightforward and rather simple. By carefully configuring Referrer-Policy, you can enhance user privacy and security on your website.

redirection.io has a recipe for this!

We provide a recipe for configuring the Referer-Policy header on your website in just a few clicks. It lets you choose the appropriate value to configure:

The Referer-Policy recipe page gives detailed hints on which value to choose for this header.

The Strict-Transport-Security header (HSTS)

HTTP Strict Transport Security (HSTS) is a security mechanism that tells browsers to only communicate with a website over HTTPS, even if the user tries to access it via HTTP. This helps protect against man-in-the-middle attacks, when an attacker intercepts communication between the user and the server.

How does the HSTS header work?

1. The server sends HSTS header: When a website is accessed for the first time over HTTPS, the server sends an HSTS header with the response. This header instructs the browser to:

• Remember the domain for a specified period (e.g., one year).
• Automatically redirect all future HTTP requests to that domain to HTTPS.

2. The browser stores the policy: The browser stores this policy locally, so it can be applied to all subsequent HTTP requests.
3. Enforced HTTPS: For subsequent visits, the browser will automatically redirect any HTTP requests to HTTPS, even if the user types the HTTP address or clicks on an HTTP link.

As of today, HSTS is not an option anymore and should be implemented in all business websites

What are the benefits of using HSTS on your website?

Adopting HSTS provides several benefits:

• Enhanced security: it protects your website against man-in-the-middle attacks by forcing HTTPS connections.
• Better user experience: it ensures that users always connect securely, even if they accidentally type the wrong URL.
• Downgrade attacks prevention: it prevents attackers from forcing the browser to downgrade to a less secure HTTP connection.

How to implement HSTS?

To implement HSTS, you need to add an Strict-Transport-Security header to your website's HTTP responses. This header typically includes two directives:

• max-age: Specifies the number of seconds the browser should enforce the HSTS policy.
• includeSubDomains: Indicates whether the policy should apply to all subdomains of the website.

The HSTS header can also include a preload directive, so browser vendors (Chrome, Firefox, Safari etc.) directly know that requests performed to your domain have to always use HTTPS.

Here's an example HSTS header:

Strict-Transport-Security: max-age=31536000;  includeSubDomains

Configuring HSTS is really a good practice, and we strongly encourage you to do so! With redirection.io, the recipe installation takes a few clicks:

Read more about HSTS recipe in our documentation.

The Permissions-Policy header

It's important to remember that today's browsers do much more than just expose web pages: the functionalities exposed by browsers are increasingly numerous, and increasingly sensitive in terms of private data. For example, a web page can request the usage of the camera, the microphone and the geolocation. It can trigger payment events, or even know if the user is on idle or currently using his computer. Such features are powerful and allowed to build rich web applications, but need to be controlled to avoid personal data leaks - with great power comes great responsibility.

The Permissions-Policy header defines the permissions of many browser functions, such as the camera, microphone, fingerprint reader, geolocation, etc. More precisely, when sent back with a response, this header instructs the browser to allow or block some functions in this web page.

In other words, setting up a Permissions-Policy security header gives you greater control over the use of these functions, and limits the risk of data leakage.

How to prevent data leakage with Permissions-Policy?

To illustrate this, let's take a very concrete example:

Let's imagine the case of "My Website", a media site which embeds several advertising scripts to monetize its content. We often imagine that advertising scripts are limited to displaying ads on the user's screen, but the reality is that many third-party scripts seek to collect as much data as possible and often operate in the form of scripts, which themselves can load other scripts, which load other scripts and so on. Open the web inspector on a mainstream media website, and you will be amazed by the number of domains that load scripts when navigating on this website! It can litterally be hundreds of domains that load javascript resources in the user's browser.

Schematically, the script loading hierarchy often looks like this:

MY WEBSITE
  │
  ├── A script 
  ├── B script 
  ├─┬ C script 
  │ ├── C1 script
  │ ├── C2 script
  │ └─┬ C3 script
  │   ├── C3.1 script
  │   └── C3.2 script
  ├─┬ D script
  │ ├── D1 script
  │ └── D2 script
  └── E script

We can see that the C script loaded by "MY WEBSITE" itself loads the C3 script, which in turn loads the C3.1 and C3.2 scripts, while "MY Website" has no direct link with the supplier of the C3.1 script.

Nevertheless, the C3.1 script will be able to access your user's browser functions, such as their camera or geolocation.

If one of the script providers in this chain has a security flaw, or has suffered an attack that has modified the inserted scripts, certain functionalities of the user's browser may be exposed to the risk of malicious use.

For example, if the company which provides the C1.3 script has been hacked, it is possible that a "MY WEBSITE" user will see a request for access to his camera triggered in his browser. The danger is twofold:

• A user who is well-informed about privacy issues runs the risk of developing a bad image of "MY WEBSITE", which would be seen as a poorly designed site, intrusive or with security flaws. This is what we call a "catastrophic experience".
• A neophyte user, on the other hand, might accept and see his or her private data leaked.

On top of that, "MY WEBSITE" would then be obliged to engage in crisis communication with its users, which could really damage its traffic and the trust of its visitors over the long term.

Yes, redirection.io has a recipe for Permissions-Policy

From the exhaustive list of browser features, you choose the appropriate configuration for your website. It's really easy to install!

Find out more in our documentation about the Permission-Policy Recipe.

While Permissions-Policy is a very efficient and robust mechanism, it is still too little used. Business websites should make it a standard security good practice.

The X-Frame-Options

Ever heard of clickjacking?

Clickjacking is a web hacking technique that involves tricking a user into clicking on an element of a web page without them realizing it.

The idea is to take advantage of the fact that many users are constantly logged on to popular websites, such as Facebook, Paypal, etc.

A hacker creates an attractive page (for example, a game or product page), and you are visiting it.

Beneath the page's graphic layer, the hacker has hidden another page, which is not visible, containing, for example, an iframe from your favorite social network - it is the website he wants to attack.

Enticed by the great product on sale on this page, you click on the button to add the product to your shopping cart, when in fact you have clicked on the button hidden beneath the page, in the iframe, which will make you, for example, post a message on your social network without knowing it.

X-Frame-Options helps you prevent from clickjacking

By using an X-Frame-Options header, you prevent from embedding your website in an iframe, which is often the first step in a clickjacking attack.

The various possible values for the X-Frame-Options header are:

• DENY: This is the most restrictive value. It categorically prohibits the integration of the page into an iframe, regardless of the origin of the request.
• SAMEORIGIN: The page can only be integrated into an iframe if the latter is on the same domain as the page itself. This prevents clickjacking attacks from other sites, but allows the use of iframes within the same site.
• ALLOW-FROM url: This value specifies a list of URLs authorized to integrate the page into an iframe. It is important to note that this option is less secure than the previous two, as it opens the door to potential attacks if the URI list is not correctly configured.

And to make life easier, redirection.io has a recipe for X-Frame-Options, which takes a few seconds to install, so you really should do it, because it's a game changer.

The Content Security Policy (CSP)

Fighting malicious content injections

Content Security Policy (CSP) is a security mechanism designed to protect websites against certain attacks, such as XSS attacks. More specifically, CSP helps to strengthen your website's security by limiting the sources of authorized content, making your website more resistant to attack. It also helps protect user privacy by controlling the resources that can be loaded, limiting the possibility of tracking and data collection by third parties.

So, for example, I can decide that on "MY WEBSITE", I only authorize scripts from my domain, and from Google Analytics. As a result, any other script added to the page, for example from a hacker, won't even be downloaded by the browser.

This header is therefore the ideal tool for combating Cross-Site-Scripting, but its implementation can be tricky... unless you use redirection.io.

How to implement Content-Security-Policy with redirection.io?

Well... Unfortunately, we don't yet have a recipe for setting up a CSP header, but redirection.io can still help on this.

To set up a CSP header, all you need to do is create a rule with a /[ANYTHING] URL trigger and a "Custom HTTP Header action" to add the CSP header to all responses served by your website. If required, you can target a narrower set of pages to test before deploying the CSP header on all pages.

The X-Content-Type-Options, to avoid code sniffing

The HTTP X-Content-Type-Options header is a security mechanism used by web servers to indicate to browsers that they should not attempt to guess (or "sniff") the content type of a resource.

Content sniffing means that the browser does not rely on the Content-Type header sent by the server, but instead determines the file type of a resource by analyzing its content. While this may seem practical, it is actually a method exploited by hackers to execute malicious code.

By sending the X-Content-Type-Options header with the value nosniff, the server tells the browser that it must strictly adhere to the content type specified in the Content-Type header. This prevents the browser from attempting to interpret the content in a different way, considerably reducing the risk of code injection attacks.

X-Content-Type-Options: nosniff

By using it, you make it clear to the browser that it must trust the type of content specified by the server, which reinforces the security of your application.

Please, use security headers for your website

This is it, you've had a complete overview of the solutions you can implement on your website to enhance security and provide better guarantees for your users.

At redirection.io, we're aware of these issues, and we respect users' privacy. That's why we're doing everything we can to help you easily and autonomously implement these solutions. redirection.io is much more than just a redirects manager, and it provides all the useful tools to test, verify and deploy security improvements on your websites.