7 Must-Use HTTP Security Headers for WordPress
When looking at any half-decent WordPress security checklist, the long line of things you could be doing to keep your website safe sure makes it look like the internet isn’t a safe place to be. Then again, how great it is to have all those various security plugins and practices to keep your website safe? Whether you need identity theft protection services, online security scanners, or ways to protect your website from DDoS attacks and avoid malvertising, there’s something you can do about it. And if you’re looking for ways to make your website even more secure, there are also HTTP security headers your WordPress website could use.
As far as website security goes, however, employing HTTP headers might not be the best-known method of keeping your website safe. Don’t worry, though – we’ll provide you with the most useful information about HTTP security headers and how your website can use them. So stick around, and read about:
Qode Themes: Top Picks
View Collection
To get to what HTTP security headers are and why your WordPress website might need them, we first need to cover what HTTP headers are and what they do. Whenever someone tries to access your website via a browser, the browser sends a request to your server, asking it to serve up the information needed to, for example, display a page or a post.
When that request goes out, it includes two components – a request line that details what is requested, and HTTP headers. Request headers might, for example, instruct on the preferred version of the content, provide information on the preferred type of connection, signal caching policies, and do many more things.
A server that receives the request sends out the response, which starts with a status line, followed by response headers, and finally the contents of the reply – the information about the page. In this case, HTTP headers can supply information about the content, including when it was last modified, for example. HTTP headers can also inform about the content caching policy – that’s what expires headers do.
You can see by now that HTTP headers give more information during the exchange of information between a browser and a server. The information can be used to help authentication purposes, caching, storage, managing the connection, setting of cookies, and many more things – including security.
So, HTTP security headers are HTTP headers that help harden your website against all sorts of online attacks and make it more secure for both you and the people who visit your website. If you’re still not sure about what they are and what they do, however, things might get clearer once we dive into specific security headers you should use for your WordPress website.
The best way to understand what HTTP security headers do is to go through a handful of them and explain what they’re used for. To that effect, we’ve created a list of some of the most useful HTTP security headers for WordPress you could implement on your website.
HTTP Strict Transport Security – HSTS
HTTP Strict Transport Security, often referred to as HSTS, is an HTTP security header you can use to prevent downgrading from an encrypted connection to your website – a connection made using HTTPS – to an unencrypted and less secure connection.
An unencrypted connection is vulnerable to various man-in-the-middle attacks, and there are various reasons a visitor might use the less secure type of connection, from clicking on an old link to browsers defaulting to the less secure version when the encrypted version isn’t written out.
If your website has an HSTS security header, it will respond to the first request from your website with information that the addresses on your website should only be opened using the encrypted connection. In essence, HSTS forces a secure connection.
Content Security Policy – CSP
Content Security Policy is an added layer of protection your website can use against cross-site scripting, data injections, and clickjacking attacks. To do so, the CSP HTTP security header specifies which resources can be loaded to display any specific page.
In practice, this means that you’ll have to create a policy with a bunch of directives that specify from which locations a user agent – a browser, for example – might download certain resources, or to which location they can navigate or use as targets for form submission, or even restrict plugins which can be embedded into a document.
As you might imagine, creating a Content Security Policy can be a challenging task. Web developers can also use the Content Security Polity Report Only header which only monitors the possible effects of policies without actually enforcing them.
Cross-Origin Resource Policy – CORP
If you want to prevent the resources from your website from being loaded on other pages – which you might do if you want to stop hackers from taking advantage of cross-site leaks – then having a Cross-Origin Resource Policy header, or CORP, comes highly recommended.
With CORP, you can set loading rules for every resource on your website. There are three types of rules you can set using this header:
-
Same-origin, which allows the resource to be loaded only by same-origin pages.
-
Same-site, which allows the resource to be loaded on all subdomains of a single site.
-
Cross-site, which allows the resource to be loaded on other sites.
Keep in mind, however, that CORP doesn’t prevent access to those resources by simply navigating to them.
Cross-Origin Opener Policy – COOP
Another way to reduce the chance of your website being a target of cross-site leaks is to make sure that same-origin documents are loaded in a separate browsing context than cross-origin documents. This is something the Cross-Origin Opener Policy, COOP, header might help you with.
COOP has three different directives:
-
Unsafe-none, which is the default directive that allows adding the document to an existing browsing context group unless that group has any of the two other directives.
-
Same-origin-allow-popups, a directive you can set if your website uses popups that transfer data across windows.
-
Same-origin is the strictest directive that puts same-origin documents into a browsing context that can’t be accessed by cross-origin documents.
Cross-Origin Embedder Policy – COEP
When you want to restrict the cross-site resources your documents can load only to the ones that give it strict permission, you use the Cross-Origin Embedder Policy – COEP. When you set the directive of this header to “require-corp,” only the resources that are allowed so using CORP will be loaded in a document. Alternatively, if the resource supports the CORS protocol, it might be used to decide its eligibility to be opened.
X-Content Type Options
The Content-Type header is an HTTP header that denotes information about the media type of a resource. When this information is ignored, the resource can be used in a way that’s not intended, for example, to execute scripts in the form of a cross-site scripting attack.
The X-Content Type Options security header is used to let the browser know that they shouldn’t ignore the MIME type set in the Content-Type header. This security header is another one you should be using on all of your resources – along with correct Content-Type headers.
X-Frame Options
Clickjacking is a type of attack where someone can use a decoy page – let’s way one from your website – to get a user to click on something on their page, which is typically hidden behind your decoy page. One of the ways attackers can do this is by rending your pages using <frame>, <iframe>, <embed>, or <object>.
You don’t have to allow for that, of course. You can use the X-Frame Options security header to deny this type of rendering. You should do so on all the documents that aren’t created specifically for embedding.
When it comes to adding security headers, you should know that some are more difficult for adding and configuring than others. This being WordPress, you’ll have the option to use plugins to help you out. It might not be the most desirable way to implement security headers, but it’s probably the easiest. The plugins that come recommended for these purposes include Redirection and the pro version of Really Simple SSL.
If you want to avoid using plugins altogether, you can go straight to the core and edit the .htaccess or Nginx.conf file, depending on the type of server you have. You’ll need to do little else except add a line or a few lines of code for each of the headers, depending on which ones you want to implement. And finally, if you’re using Cloudflare, you should know that it has its ways to let you add security headers, that save you from having to go into your server configuration file or download new plugins.
Let’s Wrap It Up!
HTTP Security Headers are simple lines of code you can use to greatly improve the safety and security of your website. Some might be complicated to write, and others might work well only in addition to existing security practices, but it’s hard to find a security header that’ll do you more harm than good – especially on a list of must-use HTTP security headers for WordPress. So check your website for the headers it already uses, and carve out the time to add the ones it still needs.
