Top HTTP Security Headers and How to Deploy Them
HTTP response headers can be used to increase the security of web applications and websites. Generally this can be done by adding a few lines of code to your application or website.
HTTP headers are fields, encoded in clear text, that are part of the HTTP request and response message header. They are designed to allow both the HTTP client and server to send and receive meta data about the connection being established, the resource being requested and the returned resource itself.
There a number of HTTP headers that have been introduced in recent years. These headers can be helpful protecting against certain kinds of attacks, so let’s look at what they are and how to implement them in your application.
Content Security Policy
Content Security Policy (CSP) was introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in a web application.
A general example of how a CSP could be implemented is to specify that your website loads images from any URI, plugin content from trusted sources (such as a content distribution network) and scripts only from a server you control:
Content-Security-Policy: default-src 'self'; img-src *; object-src media1.example.com media2.example.com *.cdn.example.com; script-src trustedscripts.example.com
For more specific configurations, read more about how to deploy a CSP in Django here and in Ruby here.
Learn more about all other Content Security Policy settings and features here.
Strict-Transport-Security
A Strict Transport Security header (HSTS) allows your application to tell browsers that it should be accessed using HTTPS instead of HTTP.
If your website or application allows connection through HTTP before redirecting to HTTPS, visitors can communicate with the non-encrypted version of the site before the redirect which creates an opportunity for man-in-the-middle attacks.
Upon a visitor’s first interaction with a website, the browser will have no knowledge of an HSTS Policy for the host, therefore the first communication is taking place over HTTP and not HTTPS. To solve this issue, browsers contain a preloaded list of sites that are configured for STS. HSTS is generally set to a “max-age” value that is high enough to keep the website cached in the HSTS list for the entire period that is defined.
The following server response is an example of an HSTS header being set to cache the domain in the HSTS list for one year:
Strict-Transport-Security: max-age=31536000;
All major browsers currently support Strict Transport Security headers, except for Opera Mini and Internet Explorer prior to version 11.
Learn more about Strict Transport Security headers here.
X-Frame-Options
The X-Frame-Options HTTP response header is used to indicate if a browser is allowed to render a page in a “frame”, “iframe” or “object” HTML tag. Sites and applications can use this to avoid clickjacking attacks, by ensuring their content can’t be embedded into other sites.
This added security only works if the visitor is using a browser that supports X-Frame Options.
It’s common practice to set this header to either “SAMEORIGIN”, or to “DENY”. “SAMEORIGIN” allows only resources which are part of the same origin policy to frame the protected resource. “DENY” denies any resource (local or remote) from attempting to frame the resource that also supplied the “X-Frame-Options” header.
This is shown below:
X-Frame-Options: SAMEORIGIN
It’s important to note that the X-Frame-Options header has been deprecated and will be replaced by the Frame-Options directive in the Content Security Policy but that is still in active development. The X-Frame Options header currently has much wider support and therefore is still an HTTP security header worth implementing.
Learn more about X-Frame Options here.
X-XSS-Protection
The X-XSS Protection header is a feature of Internet Explorer, Chrome and Safari that prevents pages from loading when they detect cross-site scripting (XSS) attacks.
The optimal configuration is to set this header to the value listed below, which will enable the XSS protection and tell the browser to block the response if a malicious script has been inserted from user input, instead of sanitizing:
X-XSS-Protection: 1; mode=block.
Internet Explorer and Chrome sanitize any malicious data by default, if no X-XSS-Protection header is sent from the server.
This header is important for older browsers that don’t support CSP.
Similar to the X-Frame-Options header, the X-XSS Protection header has been deprecated and will be replaced by the Reflected-XSS directive in the Content Security Policy. That directive is still in active development. The X-XSS Protection header currently has much wider support and therefore is still an HTTP security header worth implementing.
Learn more about X-XSS Protection here.
X-Content-Type-Options
The X-Content-Type-Options header is used by the server to indicate that the MIME types listed in the Content-Type headers should not be changed and must be followed. This lets you opt-out of MIME type sniffing.
MIME sniffing is taking a guess at what content type the server response will be, rather than trusting what the header’s content type value states. Based on that guess, browsers can be tricked to execute malicious code.
X-Content-Type-Options can be used to prevent this from happening by setting the value of this header to “nosniff” like this:
X-Content-Type-Options: nosniff
Currently, only Internet Explorer, Chrome and Safari support this header.
Learn more about X-Content-Type-Options here.
Cross-Origin Resource Sharing (CORS)
Cross-Origin Resource Sharing (CORS) is a tool that uses additional HTTP headers to allow a web application running in one location to access resources on another server at another location. The web application would make a cross-origin HTTP request to request the resource from the second origin.
Modern browsers use CORS within API containers such as XMLHttpRequest or Fetch to mitigate the risks of cross-origin HTTP requests.
For example, to permit https://www.templarbit.com to request and integrate your site’s data and content you would do the following:
Access-Control-Allow-Origin: https://www.templarbit.com
It is recommended that you do not set any CORS related headers unless you are sure you want to allow requests from other websites you do not control. A website that does not set any CORS headers, will not allow requests from any other sites.
Learn more about Cross-Origin Resource Sharing (CORS) here.
HTTP Public Key Pinning (HPKP)
HTTP Public Key Pinning (HPKP) tells a web client to associate a cryptographic public key with a certain web server. This prevent man-in-the-middle attacks by forged certificates.
You can pin either the root certificate public key or the immediate certificate.
Here is an HPKP header example from facebook.com:
public-key-pins-report-only:max-age=500; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E="; pin-sha256="q4PO2G2cbkZhZ82+JgmRUyGMoAeozA+BSXVXQWB8XWQ="; report-uri=http://reports.fb.com/hpkp/
Currently, HPKP works only in Firefox and Chrome.
Learn more about HTTP Public Key Pinning (HPKP) here.
Now that you have a better understanding about HTTP security headers, book a free demo with us to get started establishing your HTTP Security Headers.