Security headers for your site: where to start

Web security has come a long way since the internet first launched, where inquisitive programmers were able to pick apart gaps and exploit flaws in relatively new scripts and applications. Now people are far more aware of security issues, but this just presents a new challenge for “hackers” to develop smarter and more creative methods to breach website connections.

It’s likely that this will always be the case, but you can deter “hackers” from attempting to break into your website by implementing the below security headers. Our Head of SEO, Sean Devlin, takes a look at how to use security headers to safeguard your website.

Firstly, what are security headers?

Security headers are “directives”, (instructions to be followed), used by websites and web applications to make it harder for “client side”, (end user device), vulnerabilities to be exploited.

Simply put, your adding better locks on your doors!

Where are they set?

Security headers are setup at the server level, normally within the server configuration file.

Which security headers are best for me?

Firstly, I would recommend using a combination of these headers as this provide additional security from a wider range of vulnerabilities. The headers which add the most security are the “content-security-policy” and “feature-policy”.

Content Security Policy

This is probably the most secure header in our arsenal but also can cause the most problems if not implemented correctly.

The “content-security-policy” defines the “safe” resources which the browser can load. This means all the resources used by your website and third-party scripts. Resources that do not appear on his list will not be allowed to load, stopping hackers from injecting “third party” scripts during the response and request sequence.

The catch is essential resources missing from the “content-security-policy” will not be loaded, breaking your page. Our advice is to test, test, test before launch!

Feature policy

This header defines what features our website can and cannot access. For example, you may have a website that will never require access to the camera or microphone. To protect your users from potential malicious attacks, the “Feature-Policy” can be set to:

• “microphone ‘none’; camera ‘none’;”

This means if hackers we able to access and inject malicious code into your website, there would be control over features could be accessed and manipulated.

X-Frame-Options

This header controls who where a “iframe” can be added from, stopping “click jacking” by third parties injecting “iframes” into your website.

The most common settings are:

• “DENY” – (no iframes allowed)
• “SAMEORIGIN” – (only iframes from the host). This header stops iframes pointing to third party websites from launching within the browser.

I know what you’re thinking, “I have videos from “YouTube” on my website can I use this header”? Yes, you can if the referenced “YouTube” URL is “embedded” and uses “/embed/” path instead of “/watch/”.

X-Content-Type-Options

This head can stop the browser attempting to find out or guess the file type if not declared!

Browsers may attempt to determine file types when they are not labelled, (MIME sniffing), meaning you could add JavaScript within a text file and have the text file executed as JavaScript within the browser. This a vulnerability, allowing hackers to execute hidden code within a user’s browser.

We want to say if it’s not labelled, don’t execute, and this can be done by setting the “X-Content-Type-Options” header to “nosniff”.

Setting: X-Content-Type-Options: nosniff

HTTP Strict Transport Security (HSTS)

Enabling this header within the server instructs the browser to stop trusting “HTTP” requests and only accept “HTTPS” connections. This removes interception vulnerabilities during “HTTP to HTTPS” redirects and accepting resources from unsecure connections.

Google has a dedicated “HSTS preload” safe list, hardcoded into Google “Chrome”. To be entered on this list you must meet the requirements here, which also allows you to test your HSTS setup to mirror the below.

• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Referrer-Policy

A “referrer-policy” header controls how much referrer information is sent and included within requests. It protects your user data, reducing the amount of “navigation” information being collected. Be aware that tracking application such as Google Analytics use “referral” data and this header would stop the information from being sent.

The header wouldn’t stop someone hacking your website but reduces the amount of information they can collect.

Conclusion

Using a combination of security headers will make it harder for third parties to attack your website. We would recommend all website implement security headers, especially those dealing with taking online payments. Just make sure to testing functionality after every update, ensure the page loads correctly.

Useful security websites

• https://securityheaders.com – Checks security headers
• https://hstspreload.org – Googles HSTS checker
• https://www.ssllabs.com/ – SSL certificate validator and security checker
• https://safe.page – Security guidance from Google