Security has to be addressed in every area. On the level of users, browsers and servers, sure, but also in the application level. Meaning, we have to use some kind of tool to signal to the browser what functionality it’s not allowed to use while displaying your website.
HTTP response headers are supplemental information which is sent from your application to the user’s browser, thereby protecting you from various attacks.
Security is always about a balance between usability and level of safety: You should limit browsers to functionality which doesn’t pose a security threat, but limit it too much and it won’t display your website the way you want it to.
So how do you know if your security headers are doing what they are supposed to?
- Start by testing your website on securityheaders.com. use the description below to evaluate which headers you should consider using.
- You can also read more at OWASP Secure Headers Project if you’re still not sure.
- Consider what you should implement, but you should have a really good reason not to set headers which would at least give you a B-rating on securityheaders.com
- Implement! How this is done depends on your CMS.
Types of headers
HTTP Strict Transport Security (HSTS)
Demands that browsers or compatible agents should only work with programs via HTTPS – and never regular HTTP or lower versions of Transport Layer Security (TLS). Setting this HSTS-header can protect programs against devaluation of protocols. In practice this can be difficult to implement on some websites.
Recommended value: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
The X-Frame-Options header protects web apps against so-called “clickjacking” by refusing third-parties to put your website in a “frame” (a sub-container which shows your website inside another website).
Recommended value: X-Frame-Options: SAMEORIGIN
The X-XSS-Protection header is designed to protect web applications against XSS-attacks by configuring functionality which is already built into most browsers.
Recommended value: X-XSS-Protection: 1; mode=block
Prevents the browser to “sniff” the content type (MIME) and therefore forces the browser to stick to the content type defined by your website.
Recommended value: X-Content-Type-Options: nosniff
Defends against e.g. XSS and “clickjacking” by explicitly defining what content that can be loaded on the website, via a whitelist. Must be set dependent on the content actually on your site, e.g. third-party scripts.
Example of a CSP-header: Content-Security-Policy: script-src ‘self’
The Referrer-Policy’s HTTP-response coupling controls how much domain-information which is sent in the referrer-header. This limits the information shared with external sites you link to.
Example of a Referrer-Policy header: Referrer-policy: no-referrer
Limits which functionality and APIs that can be used by the browser for your site.
Not all security-related HTTP reponse headers are compatible with all browsers. OWASP offers a handy overview of what browsers support which headers.
Henrik is the Head of Insights and Analysis in Frontkom. He has 15+ years of experience as a CMS consultant, developer and web analyst. Henrik is almost obsessed in finding out what works on web and how to get there with content strategy and data analysis tools.