What Are Security Headers and How Can We Implement Them For our Website?

When a browser asks a web server for a page, the server sends back the page's content along with "headers. Some headers have meta-data about the content, like the last time the page was changed. Others include the name and version of the web server, cookies, and whether or not the browser should cache the content.

With HTTP security headers, you can tell your customer's browser how to handle the content on your site.

For example, a header could say "do not open me inside of a frame" or "only talk to me over HTTPS."

HTTP security headers such as content security policy (CSP), Http strict transport security policy (HSTS), X-Frame options, X-XSS protection header, and X-content options headers are a fundamental part of website security which we have discussed below. Upon implementation, they protect you against the types of attacks that your site is most likely to come across. These headers protect against XSS, code injection, clickjacking, etc.

Security Headers

Security headers are directives utilized by web applications to configure the security defenses of web browsers. In response to these directives, browsers can make it more difficult to exploit client-side vulnerabilities such as Cross-Site Scripting and Clickjacking. Additionally, headers can be used to configure the browser to only permit valid TLS communication and enforce valid certificates, or even to require the use of a particular server certificate.

Security headers describe HTTP response headers that your application can utilize to enhance its security. Once configured, these HTTP response headers can prevent modern browsers from exploiting vulnerabilities that are simple to prevent.

Security headers are directives that must be followed by browsers that are transmitted via the HTTP header response. Security headers impose restrictions and instructions that prevent unintended security incidents.

The sections below describe the various security headers supported by Deep Security.

1. Customizable security headers

2. Enforced security headers

3. Unsupported security headers

1.Customizable security headers

The following headers may be enabled and configured based on the needs of a particular environment:

1.1 HTTP Strict Transport Security (HSTS)

1.2 Content Security Policy (CSP)

1.1 Http Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) is a security feature that restricts web browser access to web servers to HTTPS only. This ensures the connection cannot be established using an insecure HTTP connection, which could be vulnerable to attacks.

HTTP Strict Transport Security is a header that instructs a web browser to always use a secure connection when communicating with a web application. The browser will no longer connect to the web application if the server's TLS certificate suddenly becomes invalid or untrusted. In addition, if a user attempts to access the web application via a http:// url, the browser will automatically convert it to https://. These countermeasures prevent Man-in-the-Middle attacks as well as other types of attacks, such as Session Hijacking.

How it works ...?

HTTP Strict Transport Security must first be enabled on the origin server before it can be configured.

Once it is enabled on the server, the web server will begin adding an additional response header that instructs the browser to communicate exclusively via HTTPS.

The response header will resemble the following:

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

Where,

max-age - specifies, in seconds, the duration for which the web server should only deliver via HTTPS.  

includeSubdomains - is non-mandatory (Optional). This applies HSTS to all of the site's subdomains.

preload - is optional as well. The site owner can add their site to the preload list, which is a list of HTTPS-only sites hard-coded into Chrome.

When the HTTP Strict Transport Security header is present on a website and you access it over HTTPS for the first time, the browser makes a note of it and ensures that any subsequent access to http://domain.com will be redirected to HTTPS. As long as the expiration time is not reached, the browser will comply. However, each time the header is delivered to the browser, the expiration time is updated and refreshed, thereby preventing the header from expiring.

If a secure connection cannot be established, an error message will be displayed and the user's browser will deny access to the site.

Enabling HTTP Strict Transport Security on your server

Adding HSTS to your server is simple and can be accomplished in a few steps.

Refer to the instructions below to enable it on Apache and Nginx.

Apache

To enable HSTS on your Apache server, you must edit the configuration file and add the following to the Virtual Host section.

Nginx

To enable HSTS on Nginx, add the following to the server block.

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

To determine if the HSTS header is being sent as a response header from your origin server, you can execute the following curl command:

curl -I http://keycdn.com/css/all.min.css
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 02 Nov 2015 19:07:45 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: https://www.keycdn.com/css/all.min.css
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload

1.2 Content Security Policy(CSP)

Similar to HSTS, a Content Security Policy (CSP) provides an additional layer of security via an HTTP header.

This policy helps prevent attacks such as Cross-Site Scripting (XSS) and other code injection attacks by defining content sources that are permitted to be loaded by the browser.

Without a Content Security Policy (CSP), a browser loads all files on a page without regard to their potentially harmful source. This exposes the website and its users to the risk of malicious activity.

Supported Directives

Website owners who wish to implement a content security policy can choose from a variety of directives. A CSP security header may also contain multiple directives defined by the server. The OWASP has provided the following list.

• default-src - Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback),
• script-src - Define which scripts the protected resource can execute,
• object-src - Define from where the protected resource can load plugins,
• style-src - Define which styles (CSS) the user applies to the protected resource,
• img-src - Define from where the protected resource can load images,
• media-src - Define from where the protected resource can load video and audio,
• frame-src - Define from where the protected resource can embed frames,
• frame-ancestors - Specifies valid parents that may embed a page using ,,,, or.
• font-src - Define from where the protected resource can load fonts,
• connect-src - Define which URIs the protected resource can load using script interfaces,
• form-action - Define which URIs can be used as the action of HTML form elements,sandbox Specifies an HTML sandbox policy that the user agent applies to the protected resource,
• script-nonce - Define script execution by requiring the presence of the specified nonce on script elements,
• plugin-types - Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded,
• reflected-xss - Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header,
• report-uri - Specifies a URI to which the user agent sends reports about policy violation

Note : It can be harmful to enable CSP. For instance, embedded scripts may stop functioning or specific image types needed by third-party components like jQuery may not load.

It is usually a good idea to run CSP in Report only mode before enabling it to see if any violations are reported to the specified URL for the intended application functionality.

There are numerous choices available for setting up a Content Security Policy on your web server, as demonstrated by the CSP directives listed above. CSP stands for Content-Security-Policy and is defined as

Content Security Policy: policy

Several configuration samples for your Content-Security-Policy header are shown below.

Example 1: This CSP will allow scripts from both the current domain (defined by 'self') as well as https://www.google-analytics.com.

content-Security-Policy: script-src 'self' https://www.google-analytics.com

Example 2: The default-src directive set to https: will allow the browser to load resource from any origin using https://.

Content-Security-Policy: default-src https:

Example 3 : This CSP allows for any resource to be loaded from the current domain as well as any sub domain of example.com (both HTTP and HTTPS).

Content-Security-Policy: default-src 'self' *.example.com

Implementation of CSP headers on different servers

Nginx

This snippet is placed within the configuration file.

add_header Content-Security-Policy-Report-Only:"default-src 'none'; script-src http://wordpress.keycdn.net";

Apache

The following would be placed in the configuration file

Header set Content-Security-Policy-Report-Only "default-src 'none'; script-src http://wordpress.keycdn.net;"

Once your origin server has established this CSP, you may view feedback based on the directives set by opening the console window in your browser. 

2.Enforced security headers

2.1 X-XSS-Protection

2.2 X-Frame-Options

2.1 X-XSS Protection Header

The X-XSS-Protection header is designed to enable the cross-site scripting (XSS) filter integrated into modern web browsers.This is typically enabled by default, but using this option will enforce it. It is compatible with Internet Explorer 8 and above, Chrome, and Safari. 

The recommended setting is to set this header to the following value, which enables XSS protection and instructs the browser to block the response instead of sanitizing if a dangerous script was injected from user input.

X-XSS-Protection: 1; mode=block

X-XSS-Protection directives

• A 0 value disables the XSS Filter,

            X-XSS-Protection: 0;

• The XSS Filter is activated with a 1 value.The browser will sanitise the page if a cross-site scripting attack is discovered in order to thwart it.

             X-XSS-Protection: 1;

• The XSS Filter is enabled with a value of 1; mode=block. When an XSS attack is found, the browser will prevent rendering of the page rather than sanitising it.

             X-XSS-Protection: 1; mode=block

Enabling X-XSS-Protection header on servers

Nginx

add_header X-XSS-Protection "1; mode= block" always;

Apache

header always set X-XSS-Protection "1; mode= block"

Enable on IIS

To enable on IIS simply add it to your site's Web.config file.

2.2 X-Frame-Options Header

An HTTP response header known as X-Frame-Options (XFO) or an HTTP security header. With the help of this header, your browser is instructed on how to handle the content on your site. 

It was created primarily to prevent clickjacking by not allowing page rendering in frames. 

This can involve rendering a page in an object, iframe, or frame.

Iframes are used to segregate and incorporate third-party information into websites. 

X-Frame-Options directives

Deny Directive 

The deny directive prevents any site from attempting to load a page within a frame. If this is enabled, the header request will appear as seen below.

X-Frame-Options: deny

Examples of sites currently using the deny directive:

Facebook, Github

sameorigin directive

The sameorigin directive enables a page to be loaded within a frame with the same origin as the page itself. If this is enabled, the header request will appear as seen below.

X-Frame-Options: sameorigin

When this directive is enabled, only our site may include an iframe of one of our pages.Among the three directives, this is perhaps the most common.There is a healthy balance between functionality and safety.

Examples of sites currently using the sameorigin directive:

Twitter, Amazon, LinkedIn

allow-from uri directive

The allow-from uri directive permits the page to be loaded in a frame only from the given origin and/or domain.The request header will appear as shown below when this option is enabled.

X-Frame-Options: allow-from https://www.example.com/

This allows you to lock down your site to only trusted origins. Enabling X-Frame Options Header on Servers

Nginx

To enable the X-Frame-Options header on Nginx simply add it to your server block config.

add_header X-Frame-Options "sameorigin" always;

Apache

Simply include it in your httpd.conf file to enable it on Apache (Apache config file). 

header always set X-Frame-Options "sameorigin"

Enable on IIS

To enable on IIS simply add it to your site's Web.config file.

3.Unsupported security headers

3.1 X-Content-type Options Header

The X-Content-Type-Options is an HTTP header used to do just that - increase the security of your website.

The X-Content-Type-Options header is employed to prevent MIME sniffing vulnerabilities. These vulnerabilities can emerge when a website permits users to post content, but the user disguises a certain file type as something different. This could provide them with the ability to do cross-site scripting and compromise the website.

Unfortunately, the X-Content-Type-Options: nosniff header does not provide protection against all vulnerabilities associated with sniffing. As previously stated, this header is currently only recognized by Chrome and a subset of Internet Explorer versions.If an unsupported browser accesses a resource that returns this particular response header, it will have no effect.

Enabling X-Content-Type Options Header on Servers

Nginx

Add the following code to your.conf file, Nginx users. Save your modifications and then reload Nginx.

add_header X-Content-Type-Options "nosniff"

Apache

For Apache users, simply include the following code in your.htaccess file.

Once done, save your modifications.

Header set X-Content-Type-Options "nosniff"