Security Header Guidance
Summary
The HTTP protocol supports a set of security headers to control certain aspects of (browser) behaviour. Below is a summary of the most important security headers and their suggested/required value.
There are sites like https://securityheaders.io/ and https://internet.nl/ where you can scan your site to see how well it scores. More details on scanning/monitoring below.
The links in the table below also provide examples on how to set these headers in popular web servers like Apache and nginx .
This page is inspired by the OWASP Secure Headers Project and their Configuration Proposal. We will make more of those mandatory for iO over time, so please up to speed with the below headers.
Please make sure headers are not set multiple times, as this can lead to unpredictable results.
Mandatory headers
| Purpose | Header | Explanation | Recommended value |
|---|---|---|---|
| Enforce HTTPS/TLS | Strict-Transport-Security | HTTP Strict Transport Security forces browsers to always and only access you domain vita HTTPS/TLS. | max-age=31536000 If possible, use: max-age=31536000; includeSubDomains |
Prevent Clickjacking | X-Frame-Options | X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. It's common to only allow framing of your site from your own site. This header will be deprecated at some point, so please set content-security-policy: frame-ancestors 'self' as mentioned next. | SAMEORIGIN |
| Content-Security-Policy | Content-Security-Policy: frame-ancestors header is the successor of the (deprecated) X-Frame-Options header. For now only the frame-ancestors directive is mandatory, the rest of CSP is not easily implemented because it's whitelist based and easily bypassable. In the future we may advise on implementing strict-dynamic , which is not yet easily supported by all webservers/webframeworks. | frame-ancestors self | |
| Prevent XSS filter abuse | X-XSS-Protection | The XSS Protection filters implemented in browsers turned out to provide an extra attack vector for attackers due to bugs in their implementation. The recommended value is now to turn off XSS Protection, or to not set the header at all. | do not set, or 0 |
| Prevent content type abuse | X-Content-Type-Options | X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. | nosniff |
| Prevent information leakage | Referrer-Policy | Referrer Policy is a header that allows a site to control how much information the browser includes with navigations away from a document and should be set by all sites. | strict-origin-when-cross-origin |
Optional headers
| Purpose | Header | Explanation | Recommended value |
|---|---|---|---|
| Limit impact of XSS | Content-Security-Policy | Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets. | |
| Permissions-Policy | The Permissions Policy controls which browser features are allowed to be used by your site. For example: - Battery status - Client Hints - Encrypted-media decoding - Fullscreen - Geolocation - Picture-in-picture - Sensors: Accelerometer, Ambient Light Sensor, Gyroscope, Magnetometer - User media: Camera, Microphone - Video Autoplay - Web Payment Request - WebMIDI - WebUSB - WebXR There is no single valid recommended value as it differs per web application which features are needed. Of course the safest value is none to block access to all features, but that would prevent things like fullscreen and picture in picture . | choose appropiately |
Deprecated headers
| Purpose | Header | Explanation | Recommended value |
|---|---|---|---|
| Prevent Man-in-the-middle attacks | Public-Key-Pins | HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised. Browser have stopped supporting this header as the focus shifted to Certificate Transparancy. | deprecated in browsers, but still required by some clients in mobile apps |
| Validate HTTPS/TLS certificats | Expect-CT | The Expect-CT header is used by a server to indicate that browsers should evaluate connections to the host for Certificate Transparency compliance. This headers is deprecated as since May 2018 new certificates are expected to support SCTs by default, which is checked by modern browsers. | deprecated, do not use |
Sites:
- https://securityheaders.com/
- https://internet.nl/
- https://dev.ssllabs.com/ssltest/analyze.html
- https://chrome.google.com/webstore/detail/security-header-extension/nggplilppojikmgpmlecpcikpoiffinp
Scripts:
For the Content-Security-Policy (CSP) it is a lot more complicated to check. You can use these to check the CSP: