Get Your Head Straight With WordPress HTTP Security Headers

By 4th July 2016 February 2nd, 2021 Migrated, Shield Security

HTTP Security Headers are perhaps the most overlooked way to protect visitors on your WordPress websites. But they’re one of the most powerful.

HTTP Headers tell web browsers what they can and cannot do with your website.

This is important, as it can protect your visitors from malicious content loaded from 3rd parties, as well as high-jacking (aka ClickJacking) your website.

We’ll outline what HTTP Headers are, and what we’re doing to help lock down your site. All the while never making things complicated for you or your visitors.

Sound too good to be true? Don’t worry, our clients are already used to this. ๐Ÿ˜‰

TL;DR: Secure Your WordPress With HTTP Security Headers

If you don’t have time to read the whole article, just install/upgrade your Shield installation to the latest version (v5.3+) and you’ll have a new module in there called ‘HTTP Headers’.

Turn it on and leave the settings at default for the most compatible configuration. You should rigorously test your site once this is activated as one size definitely does not fit all.

Also, see for yourself:

Scan your site both before and after you activate the HTTP Headers module to see the difference.

What are HTTP Headers?

In particular, the headers we’re referring to are the HTTP Response headers – this is the information sent out by your website when a visitor makes a request to load a page from your site.

The HTTP Response Headers are directives about the page that is about load.  Some of things covered in here are:

  • the time/date of the response
  • the protocol used
  • the (error) code
  • content caching directives
  • the server handling the response
  • cookies for the client/browser
  • … loads more

This information is used to direct how the browser will interpret, store, cache and use the forthcoming content.

Wouldn’t it be great if we could also send some security-related directive in here too?  Well now we can…

( To dig further into Headers and understand the technical aspects of this better, please see this explanation from

HTTP Security Headers – what are they and why use them?

HTTP Security Headers are a relatively new development which is why you wont see other security plugins implement these (yet).

They’re designed to protect site visitors. This helps in the event that the original website gets hacked or hijacked. It’s incredibly useful since no matter how much protection you put in place on your site, hacks can and do still occur. But what if you could safeguard your visitors that bit further in the event of such as breach?

The HTTP security headers in question here protect your visitors from a wide range of attacks including ClickJacking, Cross-Site Scripting, Cross-Site Injection.

Shield WordPress Plugin now implements HTTP Security Headers

From v5.3.0 onward of the Shield security plugin, you now have the ability to set certain HTTP Security Headers.  The particular headers available are:

  • X-Frame-Options
  • X-XSS-Protection
  • X-Content-Type-Options
  • Content-Security-Policy


The X-Frame-Options header improves the protection of web applications against ClickJacking. It lets you direct a web browser as to whether your site content may be displayed/embedded within frame on another web page e.g. through the use of iFrames ( <iframe> ).


Certain browsers come with XSS (Cross-site scripting) protection built into them. These may, for whatever, be on or off and you now have the control to explicitly turn on this extended browser protection.


This prevents certain browsers from loading content where there is a MIME type mismatch. An example of where this is useful is where certain, say user-uploaded Javascript files are actually not true Javascript files and it prevents loading of files where the mime types don’t match correctly.

Content-Security-Policy (CSP)

This is by-far the most powerful, and the most complex, of the security headers available. In essence it allows you to dictate which resources, files, etc. can be loaded/processed by the browser.

For example, can state that only Javascript files from the domain may be executed. Or, only images loaded from your domain, are downloaded. You can be as granular or as accepting as you like.

As a small example, imagine your theme was hacked and a 3rd party JS script was embedded into your site. With the appropriate CSP in-place, you would block loading of the Javascript file on the visitor’s browser.

Our implementation of this policy covers the so-called “default” directive, so it covers all types of assets, whether it’s images, scripts, objects, or styles etc.  Since most WordPress websites will use 3rd party themes, use of this is header is limited, but we’ve provided an implementation that lets you make full use of it.  This is a huge feature and full implementation is quite advanced. We’ve provided a starter configuration that you can use to build upon and create your own robust policy.

To dig into these particular security headers a little more, you can read a further summary on this over at KeyCDN here.

Why are Security Headers not featured in other security plugins?

You could ask this same question of our dynamic IP blocking and transgressions engine, of our plugin vulnerability scanning system, and our Security Administrator layer.

Our mandate is to build security that works to protect your WordPress sites and your visitors. We’re not restricted to implementing features that only other plugin developers do because it’s en vogue or we want to make a special Pro version. But you’ll probably find that in-time, they’ll implement this feature too since it make good sense and more people will start talking about it.

But by the time that happens, it might already be too late ๐Ÿ˜‰

Enjoy! ๐Ÿ˜€

Join the discussion 15 Comments

Leave a Reply

x Logo: ShieldPRO
This Site Is Protected By