Security related HTTP Headers, Part 1: Introduction

Response to each request made to the server from the client side (browser) returns the content and the special block with HTTP response headers containing various information about the content.

These headers are sent for any content: HTML page, image, AJAX response, CSS or JS files. And, these headers include information about the type of the content, size, expiration and cache related information and much more. Each header element is key/value pair. And, you can add your own headers with all kinds of information. In recent years, most important change with HTTP headers, are new headers with the goal of improving website security and protect both client and server side for malicious activity.

List of security headers

Currently, there are 7 security headers you can use (and that doesn’t mean that you need or should use all of them):

• X-Frame-Options
• X-Content-Type-Options
• Strict-Transport-Security
• X-XSS-Protection
• Public-Key-Pins
• Referrer-Policy
• Content-Security-Policy

This article will focus on first 5 headers, and the last two will get own articles next week.

X-Frame-Options

This is a very useful header that will prevent loading of your website inside the IFRAME, or to control in which cases that might be allowed. This prevents the clickjacking attacks. This form of attack depends on wrapping a website inside the IFRAME filling the screen, but the code in the IFRAME hijacks the user actions and can use them to run malicious code, get user information…

This header has 3 possible values:

• DENY: the website will not allow loading in the IFRAME.
• SAMEORIGIN: the website will allow loading in IFRAME, only if the IFRAME is part of the same website, so you can use IFRAMES on your website to load some other page from your website.
• ALLOW-FROM {url} {url}…: include the list of URLs for websites that are allowed to load your website in IFRAME.

Most commonly used option is SAMEORGIN.

Example for adding the Header

For Nginx, add directive into server config. For Apache, you can add it to main server config, or into .htaccess.

// nginx
add_header X-Frame-Options "SAMEORIGIN" always;

// apache
Header always set X-Frame-Options "SAMEORIGIN"

X-Content-Type-Options

This is a simple header to configure, and it has only one valid value. This header prevents browser to do MIME sniffing of the content type other than it was declared by the server. This prevents ‘drive-by’ downloads and problems with the content uploaded by users trying to exploit smart name to hide executable files.

Example for adding the Header

For Nginx, add directive into server config. For Apache, you can add it to main server config, or into .htaccess.

// nginx
add_header X-Content-Type-Options "nosniff" always;

// apache
Header always set X-Content-Type-Options "nosniff"

Strict-Transport-Security

This header must be used only for HTTPS based websites because it will instruct the browser to always connect to your website over HTTPS, even if the user attempts to load your website URL with HTTP. This header sets maximum age for enforcing secure connection for your website. You can read more on this header here: Scott Helme: The missing link in Transport Layer Security

Example for adding the Header

For Nginx, add directive into server config. For Apache, you can add it to main server config, or into .htaccess.

// nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains" always;

// apache
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

X-XSS-Protection

This is another header easy to setup, and very useful to enable built in protection some browsers have for XSS attacks (Cross-site scripting – method for injecting malicious scripts into the loaded web page).

Example for adding the Header

For Nginx, add directive into server config. For Apache, you can add it to main server config, or into .htaccess.

// nginx
add_header X-Xss-Protection "1; mode=block" always;

// apache
Header always set X-Xss-Protection "1; mode=block"

Public-Key-Pins

This is a very complicated header to configure, it is very rarely used, and in the recent months this header has fallen from grace and it showed some very big issues and even methods for attack based on it. I will not go into too many details, but the idea of this header is to use your SSL certificate keys to generate the header that will whitelist identities browser should trust when visiting your website.

Generating these key pins requires server access to run commands that will get the keys based on your certificates and it can be very hard thing to do for most website owners. And, this HTTP header has two very huge issues: revocation of the public key pins (in case your private key is compromised, attackers can use them to generate own keys) is not possible and RansomPKP attack that can happen if your domain gets’s hijacked. More on this you can find here: Scott Helme: I’m giving up on HPKP.

I don’t recommend using this header, and there is no way to give the example of use.

Are these headers really effective?

Short answer: yes. All these headers depend on the browser used. If the browser supports these headers, then all is OK. If not, then your website and your users might still be vulnerable to some forms of attacks. But, the good news is that all modern browsers, both desktop and mobile, support all these headers (Safari and IE might not be up to standards all the way). If users use old browsers, then they are responsible for putting themselves in the risk of malicious attacks that might target old browsers.

Coming up next…

Next week you can expect 2 more articles focusing on the last two headers.