In this guide, we answer ‘what is an http security header’, and why should you use them. Also we cover how to add security headers to your site in our other article.
What is an HTTP Security Header?
An http security header is basically a header that protects the requested website and the requesting browser from executing malicious code.
Here is an example:
Since security headers are served directly by the web server (the server the content you are viewing is on, they have apache, IIS, etc.), when a page has been injected with malicious code, the server is serving both the malicious code, as well as the security headers.
When the security header is added, you – as a user viewing the page, are prevented from seeing or interacting with the malicious code on this page, saving your day!
If the security headers were forgotten or not added, you will both see and interact with the malware on that page, and have a pretty bad day. Hence the importance of the security headers, and Google giving higher value to websites WITH security headers.
What about SSL? Doesn’t that protect a site?
Some people talk about Secure Site Locks (SSL), which is an additional layer of security on your site. However, this ONLY shows users and Google that the information being sent to the site, and being received from the site is encrypted.
So to optimize your site security, we recommend to use several important security headers on your site as well! And Google will reward you for it.
Below is a list of important Security headers you can use, and their definitions. To implement them, you can add the headers to your website’s .htaccess file. For instructions on how to do that, and more information on read how to add the security headers to your website.
When this header is set on your domain, a browser will do all requests to your site over https from then on. So in the case where a hacker is redirecting this user to a fake domain.com, the browser remembers to use SSL because of the HSTS, so requests the secure site. But this doesn’t exist: no SSL certificate was authorized for this hacker’s fake site.
For more information on HSTS, visit the HSTS cheatsheet.
The Upgrade-Insecure-Requests header provides an additional method to force http:// requests on your own domain to https://. All http:// requests will be automatically upgraded to https:// when this header is enabled.
As HSTS is only enforced after the browser visits your site, this is a vulnerability: if the user hasn’t visited your site before, HSTS won’t be set, so the visitor can still request the site over http. There is a solution for this: the HSTS preload list. This is a list of HSTS domains, that is preloaded in browsers. If you’re on the list, the browser will know that it should only load your site over https, even before it ever requests your site.
But be carefull with this feature: all subdomains (like sub.domain.com) will be forced over https as well, and removal from the preload list is very difficult, and might not propagate very fast. So even if you’re removed, browsers might have your site in the list for months yet.
This header will force the browser not to “guess” what kind of data is passed. If the extension is “.doc”, the browser should get a .doc file, not something else (a .exe). Otherwise the browser might be tricked into executing a script, while the user thinks he’s downloading an innocent file
Will stop pages from loading if a reflected cross-site scripting (XSS) attack is detected. While it should generally not be necessary when a strong Content Security Policy is in place, this will in a lot of cases not be possible on WordPress sites, as we can not be absolutely certain that inline scripts are not used in a theme. Which makes it a good thing to use this header.
The X Frame options prevent loading of the site in an iframe. The header can declare if it is allowed to load the current site in an iframe. This prevents clickjacking, by preventing the site to get secretly embedded in another site using an iframe. When using this header, you should be aware that this will block your site from showing your site in an iframe on other sites.
Expect-CT, Certificate Transparency
A Certificate Authority (the issuer of the SSL certificate) needs to log the certificates that are issued in a separate log, the CT framework. With this log fraudulent Certificate Authorities can be discovered faster, and incorrectly issued certificates can be detected quickly.
No Referrer When Downgrade header
Only sets a referrer when going from the same protocol and not when downgrading (HTTPS -> HTTP). This way a redirect will never redirect to a less secure protocol (http).
Content Security Policy
When in reporting mode, CSP can slow down your site, as the reports are fired to your server, and saved using the CSP api. If you notice performance issues, please disable reporting only on low traffic moments, until you have gathered enough data to start enforcing.
The Feature Policy header is a security header that controls which browser features can be used. Besides implementing these rules for your own content it can also prevent external iframes from using these browser features, making it a powerful header to secure your site.
The Permissions-Policy HTTP header replaces the existing Feature-Policy header for controlling delegation of permissions and powerful features. The header uses a structured syntax, and allows sites to more tightly restrict which origins can be granted access to features. This will be released in Really Simple SSL 4.1 before depracation.
This is a security header which prevents a fraudulent SSL certificate to get loaded. We won’t be adding this one, as it’s a pretty advanced one, with many risks and possible issues, and which is also deprecated by Google, essentially killing this header in my opinion.
The internet will be relying on Expect CT instead of PKP.