HTTP security headers are a fundamental part of website security and should be of top priority to everyone who publishes anything on the internet. Once the headers have been implemented, they protect your website from the most common types of attack.
These attacks are: XSS, code injection and click-jacking attacks (amongst others).
The sad truth is, security headers are often overlooked in website audits and it’s a big oversight. They involve the security of your site visitors and your customers… how would you feel if the situation were reversed?
The fallout could be really damaging to your Brand in the event of a hack, especially if it were deemed easily preventable with an HTTP Security Header. But the good news is, security headers are relatively simple to configure and will provide another layer of protection to help keep your website, and its visitors, safe.
Read on to learn what HTTP Security Headers are and how to apply the securty headers to your website.
HTTP Security Headers make your website safer for everyone.
We encourage you to check your website free of charge right now by visiting Security Headers. They will grade your website from A+ to F. Prepare yourself, you might be in for a shock.
This is a fast way of gauging how skilled your website developer is and how secure your web server and website platform is all at the same time. Your website should not score lower than a B these days, if it does it means your website is exposed to threats.
Why not type in your web developer or marketing agencies domain name and see how security conscious they are? For reference, here is our score:
How To Implement HTTP Security Headers
There are multiple ways to implement http security headers, and one popular way is with an .htaccess file. The benefit of using the .htaccess file in this case is because it saves a web developer from adding another plugin or line of code to the website.
It’s always best to avoid the plugin option. Poorly coded plugins can become a security risk in themselves, so minimising the number of installed plugins is always a wise approach. This is especially true in the case of WordPress.
But by using the .htaccess file method, it also avoids you adding lines of code to your website files which might be ‘reset’ in the event of an update. Hard code edits always carry this risk.
To find the .htaccess file. Simply login to your web hosting and open the file manager (you can also use FTP), and you’ll fine the .htaccess file present in your root folder in most cases.
The process of adding the security headers to the .htaccess file is really quite straightforward, it’s just adding lines of text after-all, but choosing the right security headers and then developing them specifically for your website – is what takes the time.
What do HTTP Security Headers look like?
For reference, here are the headers from our website. Granted, just an extract, but enough to see what they look like ‘in action’.
Any modern web browser can reveal these ‘Response Headers’ by simply inspecting the page code and viewing the network information.
Take a look at another website, see what they show in the response headers section compared to ours. It’s probably a lot less information than this:
So, now you’ve seen your website’ grade, seen where the headers live and know how to add them using the .htaccess file method. It’s time to discover exactly what they are.
Here are five HTTP security headers that you should consider implementing on your website ASAP. There are many more security headers, but these cover the basics at least.
Please note, each one needs to be tailoured especially to your website and should not be copy and pasted from our examples. We encourage you to reach out to your website developer for them to be safely implemented – or just ask us.
1. HTTP Strict Transport Security (HSTS)
The HTTP Strict Transport Security (HSTS) header tells the web browser that the entire website should only be accessed by a secure HTTPS protocol. Most websites only implement a 301 redirect from HTTP to HTTPS which simply isn’t secure enough.
It’s very easy to intercept it with what’s called a ‘man in the middle’ attack. HSTS totally prevents this and forces HTTPS every time and for every session. This ensures the connection cannot be established through an insecure HTTP connection which could be susceptible to attacks.
All modern web browsers support HTTP strict transport security except for Internet Explorer and some lesser browsers so this is highly effective and widely compatible.
Here is an example of what the header looks like. You can include the max age, subdomains, and preload:
- Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
2. Content Security Policy (CSP)
A Content Security Policy (CSP) helps prevent attacks such as Cross Site Scripting (XSS) and other code injection attacks. It achieves this by defining content sources that are ‘approved’ and by doing so, allowing the browser to load them.
All modern browsers currently offer full or partial support for content security policy and it won’t impact the delivery of the content if it’s loaded on an older web browser, it will simply not execute it.
There are many directives that you can use with Content-Security-Policy. The example below allows scripts from both the current domain which is defined by ‘self’ as well as AnaTrix the VIEWFULE Analytics Suite:
- Content-Security-Policy: script-src ‘self’ https://analytics.viewfule.com
The X-Content-Type-Options header prevent the web browser from ‘sniffing’ a response away from the declared Content-Type. This helps reduce the danger of drive-by downloads and helps serve the content the way you intended.
This is bad news for a site visitor, as it can lead to a ‘drive by download attack’. This is when there is an unintentional download of malicious code to your computer or mobile device that leaves you open to a cyber-attack.
Here is an example of what the header looks like with a simple directive to avoid sniffing:
- X-Content-Type-Options: nosniff
The X-Frame-Options security header helps stop click-jacking attacks. Click jacking is when a site visitor is tricked into clicking on a link or button (amongst others) which doesn’t do what they believed it would.
This hack can be used, for example, to steal login credentials or to get the user’s permission, completely without their knowledge, to install a piece of malware. Thankfully this problem is very easy to address with this security header and is compatible with all web browsers since Internet Explorer 8.
Here is an example of what the header looks like with a simple directive to use the same origin:
- X-Frame-Options: SAMEORIGIN
Permissions Policy is a new header, formerly known as the Features Policy. It allows a website to control which features and APIs can be used in the browser. This is achieved by communicating whether or not features such as the Webcam, Speakers or USB access will be required as a part of the website experience (amongst others).
By clearly defining these on the header, you are able to broadcast your intentions and be far more transparent with your site visitors.
Here is an example of what the header looks like with a simple directive to avoid using the Camera, Speaker or USB ports:
- Permissions-Policy: camera=(); speaker=(); usb=();
Your next steps.
At VIEWFULE, we take our clients website security seriously. HTTP Security headers are one tool we use to achieve this and when combined with a Premium SSL Certificate – it shows confidence and skill that you know how to keep your website secure for visitors and customers alike.
Implementing HTTP security headers is specific to each website and impacts whether they use an online shop or make use of external sources. The web server that’s used also matters and varies depending on whether you’re using Apache, NGINX or Litespeed. So reach out for your FREE consultation and we’ll talk through implementing these security headers, specific to your use case, on your website.