'HTTP Security Response Headers' allow a server to push additional security information to web browsers and govern how the web browsers and visitors are able to interact with your web application.

Having the appropriate Security Header Response policies in place adds another level of protection that can stop common attacks such as code injection, cross-site scripting attacks and clickjacking. For most CMS sites such as WordPress and hosts using Apache servers, these Header Response policies can be set via the .htaccess file.

This tool only detects the presence of a security policy in the header response. It doesn't validate any policies for best practices. Therefore, even if you have a 'Content Security Policy' with a wildcard, it will still pass as having detected a valid 'Content Security Policy'.

The tool was designed to help you quickly check if your server is sending response headers that have the above security policies in them. The tool adds 11 points for every detection of a security policy in the header response.

The 'X Frame Options' Security header is one of the easier policies to implement. It provides clickjack protection by preventing your website from being shown in <iframes>, <frame> or <object> tags.

By adding the below code to the top of your .htaccess file you'll ad the 'X Frame Options' response header to your site and will only allow your site to be framed by your own domain name.

<IfModule mod_headers.c>

<IfModule mod_headers.c>

By implementing the 'X XSS Protection header' you can prevent a degree of 'cross site scripting' (XSS) attacks. It's another easy security header to implement and is widely utilised by all of the huge sites such as Github, Facebook and Google.

The below snippet of htaccess code will enable the XSS filter and add another layer of security to your site:

<IfModule mod_headers.c>

<IfModule mod_headers.c>

All security policies can be contained in the one .htaccess 'Ifmodule' tag like the below example that has 3 rules in it:

<IfModule mod_headers.c>

<IfModule mod_headers.c>

The 'X Content Type Options' response header tells web browsers to disable MIME and content sniffing. This prevents attacks such as 'MIME confusion attacks'. It will reduce your site's exposure to 'drive-by download' attacks and prevents your server from uploading malicious content that is disguised with clever naming.

To add this security header to your site simply add the below code to your htaccess file:

<IfModule mod_headers.c>

<IfModule mod_headers.c>

This policy prevents any Adobe resources on your site like PDF's and Flash being abused. By adding the below htaccess snippet you'll prevent hotlinking and stop resource abuse from other sites that try to load your site's assets.

<IfModule mod_headers.c>

<IfModule mod_headers.c>

The strict transport security security header forces the web browser to ensure all communication is sent via a secure https connection. If your site is serving mixed content then implementing this will break your site. Ensure that all URLs are being served as https before adding this to your .htaccess file.

<IfModule mod_headers.c>

<IfModule mod_headers.c>

A 'Content Security Policy' header response prevents a wide array of attacks such as code injection, and XSS attacks. Unfortunately, it's also one of the most difficult policies to implement and has the greatest potential to break the appearance of your site if implemented incorrectly. In short, there is no easy way to implement this policy into your htaccess file without extensive testing.

The 'Content Security Policy' controls what host URLs (domain names) are allowed to interact with your site. Therefore, every 3rd party URL that exists within your sites plug-ins or extensions needs to be added to your Content Security Policy and then have the appropriate rules applied against them.

The first step is to document all external URLs in your site's source code, then you can use a CSP generator to create policies relating to each external URL. There is a great content security generator here: https://report-uri.com/home/generate

What makes it hard is that there are also external URLs being utilised by your site in it's JavaScript functions that you can't necessarily see in the source code. For example, analytics can introduce 5 different external URLs on your site which you can't easily see in the source code.

It's still possible to introduce a very rudimentary 'Content Security Policy' by using the below code which simply enforces that all external URLs use the https protocol. This is still better than having no policy at all and it will still let all in-line JavaScript and CSS work as well.

<IfModule mod_headers.c>

<IfModule mod_headers.c>

The 'Referrer Policy' header controls what information is passed on to the next site whenever a link is clicked on your site. It's purpose is to prevent 'Reverse TabNapping' used in phishing attcks.

If an external link has the target="_blank" attribute vaulue it provides partial access to the referring page via the 'window.opener object'. A Referrer Policy helps to prevent phishing attacks by restricting access to the 'window.opener object'.

There are a few options when setting the correct 'Referrer Policy' and you need to be careful not to set a policy that is too strict if your site deals with affiliate links. The below 3 links are great resources to learn more about the different 'Referrer Policy' options:

• Great article about Referrer Policy
• More technical specs about Referrer Policy
• More great info about noopener, noreferrer, and nofollow Values

Ultimately, it's up to you how restrictive you want your 'Referrer Policy' options to be. The below option is what I use for most of my sites:

<IfModule mod_headers.c>

<IfModule mod_headers.c>

The 'Feature Policy' security header controls what features the web browser can use while users are on your site or viewing your site through any iframe. There is a long list of features that web browsers use such as geolocation, microphones and cameras etc. The 'Feature Policy' controls which of those features may be used on your site and which origin URLs are allowed to control them.

For a comprehensive implementation guide can refer to this Google article: https://developers.google.com/web/updates/2018/06/feature-policy - For most of my sites I use this simple policy which does the following:

• Completely disable the camera/WebCam on my sites
• Allows for geolocation from any URL (geolocation *)
• Only allows the microphone to be activated from my site only

<IfModule mod_headers.c>

<IfModule mod_headers.c>

The Expect CT header policy instructs web browsers to either report or enforce Certificate Transparency requirements. This can stop miss-issued SSL certificates and can be set to either report mode or enforce mode.

Without an 'Expect CT' It's much easier for attackers to utilise miss-issued certificates. If you're going to set it to enforce mode then you definitely need to exercise caution to ensure everything is configured correctly with your SSL. On the majority of my sites I use the full enforce mode as per the below example:

<IfModule mod_headers.c>

<IfModule mod_headers.c>

You can also just use the report only mode like this:

<IfModule mod_headers.c>

<IfModule mod_headers.c>