Use Headers to Improve Security

Use secure heads to prevent attackers from gaining access to sensitive or confidential information. Here are ways to improve security on your webpages.

HTTP Strict Transport Security

Strict Transport Security (HSTS) tells the browser to communicate with a given website over HTTPS only—even if the user requests an HTTP URL.

HSTS helps protect against attacks such as SSL stripping, a type of man-in-the-middle attack first presented by Moxie Marlinspike at Black Hat 2009. In this attack, HTTPS requests to a server are “stripped” back down to HTTP, and the attacker can see and record sensitive information such as passwords and credit card numbers. HSTS prevents this attack by requiring HTTPS for all communications between the website and the browser.

You can set HTTPS options using the Strict-Transport-Security header to determine how the browser handles HTTPS for a website or domain.

Options:

• max-age <seconds> - limits HTTPS-only connections to a specified number of seconds
• include subdomains - any subdomains of the server are also limited to HTTPS
• preload - adds the domain to the browser’s default list of HSTS sites

For more information, see the OWASP HSTS Cheat Sheet.

X-Frame Options

The X-Frame-Options header specifies whether the current web page can be rendered in an iframe. This helps prevent clickjacking attacks by ensuring the content of the web page cannot be embedded into other websites where it could be used to hijack a user’s click.

Options:

• DENY - prevents browsers from rendering the current page in an iframe
• SAMEORIGIN - allows browsers to render the page in an iframe if the parent page (the page creating the iframe) is of the same origin
• ALLOW-FROM <domain> - allows the page to be rendered in iframes on pages from the specified domain.

For more information, see the OWASP Clickjacking Defense Cheat Sheet.

X-XSS-Protection

The X-XSS-Protection header instructs the browser to turn on its built-in protection against cross-site scripting (XSS), a type of injection attack in which malicious scripts are added to trusted websites.

Options:

• 0 - disable built-in XSS filtering
• 1 - enable built-in XSS filtering
• mode=block - instead of filtering the page, the browser prevents page rendering if an attack is detected
• report=<URL> - the browser filters the page and reports any detected attack to the specified URL

For more information, see Mozilla’s X-XSS-Protection page.

Referer-Policy

The referer-policy [sic] header prevents leakage of sensitive information through the referrer header to third-party websites by controlling what information is sent while making HTTP requests.

Options:

• no-referrer - the browser omits the referrer for all requests
• no-referrer-when-downgrade - the browser sends the referrer when the protocol level is the same but will not send the referrer to a lower-security destination (from HTTPS to HTTP, for example). This is the default behavior of all modern browsers.
• origin - the browser sends the origin of the webpage as the referrer.
• origin-when-crossing-origin - the browser sends a full URL as the referrer when performing a same-origin request, but sends the origin of the webpage as the referrer otherwise.
• same-origin - the browser sends the referrer for same-site origins and blank referrer info otherwise.
• strict-origin - the browser sends the origin of the document if the protocol security remains the same but will not send the referrer to a lower-security destination.
• strict-origin-when-cross-origin - the browser sends the full URL as the referrer when performing a same-origin request but follows the strict-origin rule for cross-origin requests.
• unsafe-uri - the browser sends the full URL as the referrer when performing a same-origin or cross-origin request.

For more information, see Mozilla’s Referrer Policy page.

Cache-Control

The Cache-Control header tells browsers what data to cache and for how long. This helps both performance and security by allowing the server to instruct the browser to cache public, private, and sensitive information in different ways.

Options:

• Max-Age=<seconds> - the browser caches the response for the specified number of seconds
• No-Cache - the browser submits a request to the origin server for validation before releasing a cached copy
• No-Store - the browser will not cache a response
• Public - the response can be stored by any cache.
• Private - the response is intended for a single user and must not be stored by a shared cache.

For more information, see Mozilla’s Cache-Control page.

X-Content-Type-Options

The X-Content-Type-Options header restricts the browser from trying to guess the content type of the response, forcing the browser to adhere to what is specified in the Content-Type header. This helps prevent content sniffing, which can transform non-executable MIME types into executable MIME types.

Options:

• nosniff - the browser adheres to the MIME type specified in the response headers and will not try to guess the type of content sent in the response.

For more information, see Mozilla’s X-Content-Type-Options page.

Feature Policy

The Feature Policy header is relatively new and instructs the browser to selectively enable or disable various browser features and APIs for use on the website. The aim is to lock down applications to prevent the execution of content that might introduce unwanted or unexpected behaviors.

Options:

• <feature> none - disables the specified feature for all browsing contexts regardless of origin
• <feature> self <urls> - enables the specified features only for the specified domains

For more information, see the Web Platform Incubator Community Group’s page about Feature Policy.

Content Security Policy

The Content-Security-Policy (CSP) header is designed to prevent and report XSS attacks. While powerful, this header is not straightforward. There is a bit of work involved figuring out which origins to allow for which actions for any given situation.

For more information, see Mozilla’s CSP page.