Increase your website security with HTTP response headers

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.

Contact Frontkom for help with implementing headers on your site

• 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

X-Frame-Options

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

X-XSS-Protection

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

X-Content-Type-Options

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

Content-Security-Policy

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’

Referrer-Policy

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

Feature Policy

Limits which functionality and APIs that can be used by the browser for your site.

Browser support

Not all security-related HTTP reponse headers are compatible with all browsers. OWASP offers a handy overview of what browsers support which headers.