Scoring A+ on SecurityHeaders

Tip 18: Scoring a A+ on SecurityHeaders.com 🔒

The browser is our first line of defence for protecting the end-users of our websites and web applications against things like cross-site scripting, click-jacking and nefarious tracking.

You’re probably familiar with HTTPS, which is tablestakes for websites these days - but there are a whole bunch of other protections that you can enable via HTTP Headers.

SecurityHeaders.com is a free site, built by fellow Brit Scott Helme, which will help you test them and this is an (admittedly brief) overview of how I scored an A+ for LessonsofaCTO.com.

(Note: you the below are all linked up on the website)

There are 3 headers that have pretty much static values that most sites can apply:

`x-content-type-options: nosniff` tells the browser to avoid automatically determining content type and solely rely on the content-type header your server sent.
`x-frame-options: deny` tells the browser this website should never be placed inside a frame or iframe.
`x-xss-protection: 1; mode=block` has been replaced with Content Security Policy really but enables cross-site scripting protection in older browsers.

Then there are 3 more with a little more variability, but they are fairly simple:

`strict-transport-security` tells the browser that any subsequent requests must be rewritten to HTTPS, even if the user types in HTTP and you redirect anyway. You want a decent TTL to cover time between sessions, ideally include all your subdomains and set the preload option so browsers can include you in their HTTPS-only lists.
`referrer-policy` controls what Referer header is sent when you click on any outbound links, so you can protect your user’s privacy with a value like `strict-origin-when-cross-origin` which will only send the domain, not the full URL they were on and only when the outbound website is requested over HTTPS.
`feature-policy` and it’s replacement `permissions-policy` are basically the same thing, you’ll just want to set both for backwards-compatibility. They are blocklists for browser APIs like geolocation, camera and microphone access. so you can ensure that third party scripts do not access any features you don’t want them to, again helping respect your users privacy.

`content-security-policy` is the big boy, I could do a multiple videos on this alone. It effectively controls where data can be loaded from and sent to, effectively being an allowlist per content type. It can get tricky when you’re using third parties that can change over time.

On my site: the default policy is to allow only first party requests, CSS can only be inline style tags validated with SHA256 hashing, no JavaScript at all can be loaded and images must either be first party or inline data.

Where most sites trip up is allowing ‘unsafe’ inline scripts and styles which makes you susceptible to Cross Site Scripting from compromised third parties or user-submitted content. You really need to supply hashes or nonces to prevent this.

I’d love to hear what you score for the sites you work on and provide help if you need it, so give SecurityHeaders.com a go and let me know in the comments below!

#webdevelopment #webdeveloper #websecurity #codingreels