WordPress Website Security Headers

Website Security Headers for .htaccess

HostingTipsWeb Development

Your website is missing security headers

Are you running website security checks and being told that you are missing secure headers or security headers? (Free check here)
Security headers prevent hackers and bots attacking your website and causing mayhem. Some of the ways they can do this is through code injection, click-jacking, cross-site scripting and so on. Either way they all need to be squashed and the security headers is the way to do this.

Below we have gathered up the most common ones for you to take and use as you wish. Specifically for us in the .htaccess file on your server. If you’d like more detail on the various attributes and definitions then check out Really Simple SSL. We recommend reading up on which ones do what so that you can make any changes you want. However the below will give you some basic protection.

To be copied and pasted into your .htaccess file, your server configuration may require you to ‘show hidden files’ before you can see this file. What you copy and paste into your .htaccess is your responsibility.

[sourcecode language=”plain”]
<IfModule mod_headers.c>
Header always set X-Frame-Options &quot;SAMEORIGIN&quot;
Header always set X-Content-Type-Options &quot;nosniff&quot;
Header set X-XSS-Protection &quot;1; mode=block&quot;
Header set X-Permitted-Cross-Domain-Policies &quot;none&quot;
Header always set Strict-Transport-Security &quot;max-age=31536000; includeSubDomains; preload&quot; env=HTTPS
Header always set Expect-CT &quot;max-age=7776000, enforce&quot;
Header set Referrer-Policy &quot;strict-origin-when-cross-origin&quot;
Header always set Content-Security-Policy &quot;upgrade-insecure-requests;&quot;

A quick website Security Headers breakdown

This line helps prevent against cross-site scripting whereby your content can be loaded in iframes on other domains. The setting above is set to ‘sameorigin’ meaning the content of this domain can be set into a iframe on this domain and an subdomain. A another good option is setting this to ‘deny’.

The line here enforces the content type set by the header so that browsers don’t detract or ‘be forced’ due to a malicious script to use something different.

This translates to old (ex) – Cross-Site Security. This line is actually deprecated now as modern browsers don’t rely on the old systems that were compromised by script injection. However, it’s never a bad idea to have it anyway in case a very old browser is used in an attack.

This security header line blocks the loading of Flash or PDF documents within your site from external URLs.

Ahh, this one is a must have! This enforces SSL and the use of HTTPS in securing encrypted information. It’s set to force SSL links for the next 1 year (31536000 seconds = 1 year) and include all sub domains e.g https://yoursite.co.uk/something. Lastly the ‘preload’ part prompts the site to load from an official HTST list to help quicker load times.

This is all about the nasty art of ‘spoofing’, specifically Certificate spoofing. Enforcing Certificate Transparency allows the certificate to be verified before being passed. The time period is set to the next 3 months.

This control the passing of referrer data between servers and URL’s. In our version above referrer information is only sent when the request is from the same origin. Furthermore, it will only send over HTTPS. There are many other alternatives to ‘strict-origin-when-cross-origin’ but this, for us is the best one to use.

A complex one that handles a lot of tricky business! This essentially sets what content is allowed to be presented to the network and from where. You can specify specific domains but for a WordPress site using multiple plugins this can be a pain. Listing all the external source URL’s in the tag is just a task that will take you some time. Alternatively, setting to ‘self’ is just a no go for us as some of our scripts are hosted externally and not on our server/domain. We use ‘upgrade-insecure-requests’ meaning that external scripts can be used as long as its over SSL/HTTPS.

An extra one that you might see in Security Header check results

We can’t include this one in our script above purely due to the fact that it is so dependant on the user’s requirements. The attributes and definitions that can be used are very broad!

Feature Policy
This line of script will define what features can and can’t be accessed in your browser via the website. Some definitions can be set to report what has been attempted, such as certain outdated scripts being published. Some more advanced details can be found here.

If you just want it all handled for you…

Really Simple SSL Pro has a feature that allows you to turn on security headers which will handle them all for you dynamically. It includes helpful tips and guidance on each aspect for a full resource on Security Headers. We’re big fans and Really Simple SSL – a solid reliable plugin with many benefits and uses.

We hope this quick and brief .htaccess Website Security Headers post helps you in some way! Please get in touch if you’d like any help!

Website Security Headers Really Simple SSL
Website Security Headers Really Simple SSL
Image source: https://really-simple-ssl.com