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 header options that have been introduced in recent years. These headers can be helpful protecting against certain kinds of attacks. Here are the top security headers and how to implement them in your application or website.
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. This is shown in the spreadsheet below.
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.
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.
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.
Content Security Policy with DjangoThe 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 show in the spreadsheet below.
Learn more about X-Frame Options here.
Content Security Policy with DjangoThe 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.
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.
Content Security Policy with DjangoThe 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.
Currently, only Internet Explorer, Chrome and Safari support this header.
Learn more about X-Content-Type-Options here.
Content Security Policy with DjangoCross-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.
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) 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.
Currently, HPKP works only in Firefox and Chrome.
Learn more about HTTP Public Key Pinning (HPKP) here.
Templarbit will help you set up all necessary http security headers to ensure your team is ready for emerging security threats. Preventing attacks before they affect your business is the best line of defense.
Sign Up