Response Headers

💡 The collection of HTTP response security headers mentioned in this section is applicable when the user agent processing the HTTP response is a browser. The support for these headers by non-browser API clients (user agent), like for example an HTTP client in a programming language, is not standardized. So, it requires specific testing to identify if an HTTP response security header is supported or not by such HTTP client.

🚦 Header lifecycle flow:

📐 Working draft

• Permissions-Policy

✅ Active

• Strict-Transport-Security
• X-Frame-Options
• X-Content-Type-Options
• Content-Security-Policy
• X-Permitted-Cross-Domain-Policies
• Referrer-Policy
• Clear-Site-Data
• Cross-Origin-Embedder-Policy
• Cross-Origin-Opener-Policy
• Cross-Origin-Resource-Policy
• Cache-Control

⏰ Almost deprecated

None

❌ Deprecated

• Feature-Policy
• Expect-CT
• Public-Key-Pins
• X-XSS-Protection
• Pragma

Strict-Transport-Security

HTTP Strict Transport Security (also named HSTS) is a browser security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and within a defined timespan (max-age) not via the clear text HTTP protocol. HSTS is an IETF standard track protocol and is specified in RFC 6797. A server implements an HSTS policy by supplying a header (Strict-Transport-Security) over an HTTPS connection (HSTS headers over HTTP are ignored).

📍 Important note about the behavior of the header over a HTTP connection (source Mozilla MDN):

• The Strict-Transport-Security header is ignored by the browser when your site has only been accessed using HTTP.
• Once your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header.

💡 If you need to let the access open, via HTTP, to the web server but want to ensure that Strict-Transport-Security header is taken into account for your site then you can use the preload directive.

Values

Example

Strict-Transport-Security: max-age=31536000

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

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

References

• https://tools.ietf.org/html/rfc6797
• https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html
• https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security.html
• https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
• https://www.chromium.org/hsts
• https://hstspreload.org/
• https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
• https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html
• https://blogs.windows.com/msedgedev/2015/06/09/http-strict-transport-security-comes-to-internet-explorer-11-on-windows-8-1-and-windows-7/

X-Frame-Options

The X-Frame-Options response header (also named XFO) improves the protection of web applications against clickjacking. It instructs the browser whether the content can be displayed within frames.

The Content-Security-Policy (CSP) frame-ancestors directive obsoletes the X-Frame-Options header. If a resource has both policies, the CSP frame-ancestors policy will be enforced and the X-Frame-Options policy will be ignored.

Values

Example

X-Frame-Options: deny

References

• https://tools.ietf.org/html/rfc7034
• https://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01
• https://tools.ietf.org/html/draft-ietf-websec-frame-options-00
• https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
• https://portswigger.net/web-security/clickjacking
• https://blogs.msdn.microsoft.com/ieinternals/2010/03/30/combating-clickjacking-with-x-frame-options/
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors

X-Content-Type-Options

Setting this header will prevent the browser from interpreting files as a different MIME type to what is specified in the Content-Type HTTP header (e.g. treating text/plain as text/css).

Values

Example

X-Content-Type-Options: nosniff

References

• https://msdn.microsoft.com/en-us/library/gg622941%28v=vs.85%29.aspx
• https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

Content-Security-Policy

A Content Security Policy (also named CSP) requires careful tuning and testing after definition of the policy. A content security policy can have significant impact on the way browsers render pages (e.g., inline JavaScript or CSS can disabled). A proper CSP can prevents a wide range of attacks, including cross-site scripting, other cross-site injections and click jacking.

Values

Example

Content-Security-Policy: script-src 'self'

References

• https://www.w3.org/TR/CSP/
• https://developer.mozilla.org/en-US/docs/Web/Security/CSP
• https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
• https://scotthelme.co.uk/content-security-policy-an-introduction/
• https://report-uri.io
• https://content-security-policy.com
• https://report-uri.com/home/generate
• https://csp-evaluator.withgoogle.com/

X-Permitted-Cross-Domain-Policies

A cross-domain policy file is an XML document that grants a web client, such as Adobe Flash Player or Adobe Acrobat (though not necessarily limited to these), permission to handle data across domains. When clients request content hosted on a particular source domain and that content makes requests directed towards a domain other than its own, the remote domain needs to host a cross-domain policy file that grants access to the source domain, allowing the client to continue the transaction. Normally a meta-policy is declared in the master policy file, but for those who can’t write to the root directory, they can also declare a meta-policy using the X-Permitted-Cross-Domain-Policies HTTP response header.

Values

Example

X-Permitted-Cross-Domain-Policies: none

References

• https://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/xdomain.html
• https://rorsecurity.info/portfolio/new-http-headers-for-more-security
• https://gf.dev/cross-domain-policy-test

Referrer-Policy

The Referrer-Policy HTTP header governs which referrer information, sent in the Referer header, should be included with requests made.

Values

Example

Referrer-Policy: no-referrer

References

• https://www.w3.org/TR/referrer-policy/
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

Clear-Site-Data

The Clear-Site-Data header clears browsing data (cookies, storage, cache) associated with the requesting website. It allows web developers to have more control over the data stored locally by a browser for their origins (source Mozilla MDN). This header is useful for example, during a logout process, in order to ensure that all stored content on the client side like cookies, storage and cache are removed.

Values

Example

Clear-Site-Data: "cache","cookies","storage"

References

• https://w3c.github.io/webappsec-clear-site-data/
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data
• https://www.chromestatus.com/feature/4713262029471744
• https://github.com/w3c/webappsec-clear-site-data
• https://github.com/w3c/webappsec-clear-site-data/tree/master/demo

Cross-Origin-Resource-Policy

This response header (also named CORP) allows to define a policy that lets web sites and applications opt in to protection against certain requests from other origins (such as those issued with elements like