WordPress Security Headers

Security headers in WordPress created to protect websites from frequent and frequent attacks. Without the need to add or change anything in the code of your website.

Website or web app security has many aspects to consider, and a good place to start strengthening. The security of WordPress sites would be by adding Security Headers.

What areWordPress Security Headers?

The same security headers in WordPress help add an extra layer of security. To prevent attacks and protect your site from various vulnerabilities and attacks. In this post, we will go over the various Security Headers. And see how to add these to your site in favor of better powerful site security.

I will not explain the parameters of each of the Security Headers, but we will look at the code snippets. That you need to add in the relevant file, whether on an Apache server or an NGINX server.

It is important to note that the settings I present in this post are not suitable for every site. So you should do some trial and error and be sure to check the site and see. That there are no errors in the console after each change. Often, only a specific Security Header from. Those we have presented will be problematic. Either way, back up the file before starting work and make sure you have access to the files. We change even if the site crashes (FTP access for example).

I am not an expert on this specific issue, so if there is a problem I suggest you consult a professional. In any case, and since I do not specify the parameters of each Security Header I will present, know that you can get more information at the following link. Beyond that, there may be important information you will find in the post comments.

Some WordPress Security Headers Recommended to Add

Here are some recommended security headers for WordPress sites.

HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) allows web servers to declare. That browsers (or any acceptable User Agent) should interact with them. Only through the secure HTTPS protocol and never through the secure HTTP protocol.

You can add the same HSTS Security Header by adding many rows to a .htaccess file on Apache servers. Or to an Nginx.conf file on NGINX servers. The two snippets for each of these listed below:

APACHE

Header always set Strict-Transport-Security ״max-age=31536000; includeSubDomains״

NGINX

add_header Strict-Transport-Security max-age=31536000;

X-Frame-Options

X-Frame-Options protects surfers from Clickjacking attacks. Using the iframe the content of your site can be uploaded to other sites. You can take advantage of this and cause a situation where a user clicks on some external link that seems innocent, but they are actually navigating your site.

This can be especially dangerous in situations where the user has been logged in to an area that requires some connection to your site.

APACHE

Header always append X-Frame-Options SAMEORIGIN

NGINX

add_header X-Frame-Options "SAMEORIGIN" always;

X-XSS-Protection

X-XSS-Protection is a Security Header that allows you to configure XSS-Protection from an existing mechanism in browsers. For example, theft of session cookies when the user is logged in to the site.

APACHE

Header set X-XSS-Protection "1; mode=block"

NGINX

add_header X-Xss-Protection "1; mode=block" always;

X-Content-Type-Options

Setting the X-Content-Type-Options map will prevent the browser from interpreting files as something other than the content type in the HTTP Header. There are many possible parameters in this Security Header, but the most common one used is called nosniff:

APACHE

Header set X-Content-Type-Options nosniff

NGINX

add_header X-Content-Type-Options "nosniff" always;

 Content-Security-Policy

TheHeader Content Security Policy helps you reduce XSS risks in modern browsers by announcing what dynamic resources can be loaded.

APACHE

Header set Content-Security-Policy default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';

NGINX

add_header Content-Security-Policy "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';";

Referrer-Policy

The Header Referrer-Policy Specifies to modern browsers how to manage or filter the Referer header that contains information indicating where the request came from.

APACHE

Header set Referrer-Policy "same-origin"

I added the following code to the .htaccess file: in a Woocommerce store on an apache server

APACHE

<IfModule mod_headers.c>

Header set Strict-Transport-Security "max-age=31536000" env=HTTPS

Header set X-XSS-Protection "1; mode=block"

Header set X-Content-Type-Options nosniff

Header always append X-Frame-Options SAMEORIGIN

Header Referrer-Policy: no-referrer-when-downgrade

Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' 'unsafe-eval' https: data:";

</IfModule>

If we check the result of this store on securityheaders.com we get the following result:

Regarding the Permissions-Policy which we did not mention in the current post, if you know what the recommended setting is for WordPress sites and in general you are welcome to share us in the comments…

A further check of the security level on your site can be obtained at webpagetest.org by checking your URL. Here is the result of that store: