7 Must Use HTTP Security Headers

Whenever you send a request from your browser, the server responds with content along with HTTP response headers. These response headers contain alot of information like Status, Content-Encoding etc.

Along with, there are some other security headers that tell your browser how to behave when handling your website’s content.

These HTTP response headers can use to increase the security of your application which restricts modern browsers from running into easily preventable vulnerabilities. Usually these headers protect the website against XSS, Code Injection, Clickjacking etc.

Let’s have a look at 7 HTTP Security Headers that will give your site some much needed protection:

Content Security Policy (CSP)
X XSS Protection
HTTP Strict Transport Security (HSTS)
X Frame Options
X Content Type Options
Public Key Pins (PKP)
Access-Control-Allow-Origin

1. Content Security Policy (CSP)

This CSP header allows web site administrators to control the resources of a page. This header always add an extra layer of security which helps to detect & mitigate various types of attacks such as injection attacks, XSS attacks etc.

Content-Security-Policy tells the web-browser what resource locations are trusted by the web-server and are okay to load.

Here is the list of sites where you can easily scan/generate/validate your website for CSP:

Syntax:

content-security-policy: policy

Example (Whitelisting of a domain):

content-security-policy: default-src ‘self’ https://www.yeahhub.com

Case 1 – Allow content to come from the site’s own origin (excludes subdomains.)

Content-Security-Policy: default-src ‘self’

Case 2 – Allow content from a trusted domain and all its subdomains

Content-Security-Policy: default-src ‘self’ *.trusted.com

Case 3 – Allow everything from the same origin and execution of inline and dynamic javascript

Content-Security-Policy: default-src ‘self’; script-src ‘unsafe-inline’ ‘unsafe-eval’

Case 4 – Allow only scripts from the same origin

Content-Security-Policy: script-src ‘self’;

Alternatively, the <meta> element can be used to configure a policy, for example:

<meta http-equiv=”Content-Security-Policy” content=”default-src ‘self’; img-src https://*; child-src ‘none’;”>

In case of Apache, use the following code in your httpd.conf file or in an .httaccess file.

Header set Content-Security-Policy “default-src ‘self’;”

For Nginx, use the following piece of code in your server {} block:

add_header Content-Security-Policy “default-src ‘self’;”;

For IIS, add the following code in your web.config file:

<system.webServer>
<httpProtocol>
<customHeaders>
<add name=”Content-Security-Policy” value=”default-src ‘self’;” />
</customHeaders>
</httpProtocol>
</system.webServer>

For more reference, https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

2. X-XSS-Protection

This header is basically designed to protect the websites to enable the cross site scripting filter which is usually enabled by default, but with this implementation, it will enforce that filter.

x-xss-protection header has been supported by Internet Explorer (IE) for many years. So in the case that someone is using IE<12, CSP is useless where x-xss-protection can help.

For this header, there are 4 directives which you can use:

X-XSS-Protection: 0 This will disable the XSS Filter
X-XSS-Protection: 1 This will enable the XSS Filter and if any XSS attack is detected, it will automatically sanitize the content of the page and will block all script execution
X-XSS-Protection: 1; mode=block It will be used as a block mode which will further prevent the rendering of the page if any XSS attack detected
X-XSS-Protection: 1; report=<reporting-URI> If any attack got detected then the page will sanitize and reported by report-uri directive

For Apache servers, you can use the following code and add in your htaccess configuration (httpd.conf) file:

<IfModule mod_headers.c>
Header set X-XSS-Protection “1; mode=block”
</IfModule>

For Nginx Servers, add the following code in your nginx.conf file.

add_header X-XSS-Protection “1; mode=block”;

3. HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites against protocol downgrade attacks and cookie hijacking which allows web servers to declare that web browsers should interact with it using only HTTPS connections.

There are a few things about HSTS before you go ahead and add the appropriate header:

You must have an valid SSL certificate installed on your website already
If you have sub-domains you will need to use a wildcard to protect them
You must use 301 redirects to reroute all HTTP pages to HTTPS ones
Google says best practice is two set a max age of two years
SubDomain and preload headers must be included

Example:

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

For Apache Servers, you can use the following code and add it in your httpd.conf file:

set Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”

As of September 2019 HSTS is supported by all modern browsers, with the only notable exception being Opera Mini.

4. X Frame Options

This header basically improves the protection of web applications against clickjacking attacks. By implementing this header, you instruct the browser not to embed your webpage in IFRAMEs.

There are 3 directives are available for this header:

X-Frame-Options: DENY In this , the page cannot be displayed in a frame.
X-Frame-Options: SAMEORIGIN In this, the page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM https://example.com/ This is an obsolete directive that no longer works in modern and latest browsers.

For Apache servers, you can use the following code and add in your httpd.conf file:

Header always append X-Frame-Options DENY

For Nginx servers, add the following code in your nginx.conf file:

add_header X-Frame-Options “DENY”;

For WordPress based CMS, you can use the following code:

header(‘X-Frame-Options: DENY’);

5. X-Content-Type-Options

This HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed.

For example, if a browser requests a script, but that script is served with an incorrect media type (e.g. x/x), the browser will still detect the script and execute it.

Syntax: X-Content-Type-Options: nosniff

For Apache servers, you can use the following code:

Header set X-Content-Type-Options nosniff

For Nginx servers, add the following code in your nginx.conf file:

add_header X-Content-Type-Options nosniff;

6. Public Key Pins (PKP)

HTTP Public Key Pinning (PKP) is a security feature/header that tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates.

Although public key pinning can reduce the risk of a MITM attack, it’s not a perfect defense against attackers – especially those capable of passing certificate chain validation procedures.

To implement this, following Public key Pins header should be included in the response to the client.

Public-Key-Pins: pin-sha256=”base64==”; max-age=expireTime; includeSubDomains; report-uri=”reportURI”

Where,

pin-sha256 – The value of this parameter should contain the base 64 encoded value of Subject Public Key Information (SPKI).

To generate the SPKI from the certificate we can use OpenSSL:

openssl x509 -pubkey < tls.crt | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64

Here tls.crt is the location of the certificate file. This command will print the SPKI in to the terminal. If we want to create the SPKI from the Certificate Signing Request(CSR), following command can be used.

openssl req -pubkey < tls.csr | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64

Instead of pinning the public key, we can also pin the certificate. But it is recommended to use public keys.

max-age – The value of this parameter should contain how many seconds does the browser needs to keep the keys pinned.
includeSubdomains – An optional parameters for enforcing public key pinning to every sub domain of the site.
report-uri – An optional parameter to specify the URL endpoint to report if a validation failure occurs.

7. Access-Control-Allow-Origin

The Access-Control-Allow-Origin response header indicates whether the response can be shared with requesting code from the given origin.

Syntax:

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Origin: null

By responding with Access-Control-Allow-Origin: *, the requested resource allows sharing with every origin. This header is applicable for wildcard that allows all domains.

An Access-Control-Allow-Origin (ACAO) header in its response indicating which origin sites are allowed.

Access-Control-Allow-Origin: http://www.example.com

Since www.example.com matches the parent page, the browser then performs the cross-origin request.

The HTTP headers that relate to CORS are:

Request headers

Origin
Access-Control-Request-Method
Access-Control-Request-Headers

Response headers

Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
Access-Control-Max-Age
Access-Control-Allow-Methods
Access-Control-Allow-Headers

For Apache Servers, you can add the following code within .htaccess file:

<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin “*”
</IfModule>

For Nginx Servers, CORS can be enabled using HEADERS core module as shown below:

add_header Access-Control-Allow-Origin *;

Web servers often give full version information in a HTTP Header by default. Besides these headers, there are some headers which may reveal some sensitive information about your server or application:

1. Server
This header generally contains the information about the backend server (Name and Type).