'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 six core policies (X Frame Options, X Content Type Options, Strict Transport Security, Content Security Policy, Referrer Policy and Permissions Policy) carry the bulk of the score at 16 points each. The three Cross Origin policies and X Permitted Cross Domain Policies are informational and add 1 point each. If your site is still sending deprecated headers such as X-XSS-Protection, Expect-CT or the old Feature-Policy, the tool flags them so you can remove them.

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>

No. The 'X XSS Protection' header is deprecated and does nothing in modern browsers. Chrome removed its XSS Auditor in 2019, Edge followed soon after, and Firefox never implemented it at all. Current OWASP guidance is to leave this header out entirely, because on older browsers the filter it controlled could be abused to create vulnerabilities rather than prevent them.

If your server still sends it nothing breaks, but it signals stale configuration, and this tool will flag it for removal. The modern protection against cross-site scripting is a well-built 'Content Security Policy'. To remove the old header on Apache servers, delete the rule from your .htaccess file or unset 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 only ever applied to Adobe products such as Flash and PDF readers, telling them whether they could load data from your domain. With Flash long retired, the header has little practical effect on the modern web, which is why this tool treats it as informational rather than part of the core score. It costs nothing to keep, and OWASP still lists it, so if you want the complete set:

<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 'Permissions Policy' header controls which browser features can be used while people are on your site or viewing it through an iframe, covering things like geolocation, the camera and the microphone. It replaced the older 'Feature Policy' header in 2020, and the two use different syntax, so old Feature Policy rules cannot simply be renamed.

If your server still sends 'Feature-Policy', swap it for the modern equivalent. The below policy disables the camera completely, allows fullscreen and the microphone on your own site only, and allows geolocation from anywhere:

<IfModule mod_headers.c>

<IfModule mod_headers.c>

No - the 'Expect CT' header is obsolete and can be removed. It was a transitional measure while Certificate Transparency was rolled out across the SSL certificate industry. Since mid 2018, browsers have required Certificate Transparency for all newly issued certificates by default, so there is nothing left for the header to enforce. Chrome has removed support for it entirely and it is marked as deprecated in every major reference.

If your configuration still sets it, this tool will flag it. Remove the rule from your .htaccess file or unset it:

<IfModule mod_headers.c>

<IfModule mod_headers.c>

These three headers are the newest additions to the security header family and control how your site interacts with other origins. 'Cross Origin Opener Policy' isolates your pages from cross-origin windows, 'Cross Origin Resource Policy' controls which origins may embed your resources, and 'Cross Origin Embedder Policy' requires that everything your page loads has opted in to being embedded.

They exist mainly to defend against Spectre-class side-channel attacks and to unlock browser features that need full cross-origin isolation. Adoption is still growing across the web, so this tool reports them as informational rather than scoring them heavily. A sensible starting point for most sites:

<IfModule mod_headers.c>

<IfModule mod_headers.c>

Only add 'Cross Origin Embedder Policy' after careful testing, as it will block any embedded content that has not opted in - including things like YouTube embeds and third party images.