WordPress Security Headers (or HTTP security headers) were created to protect applications from frequent and common attacks without the need to add or change the code of your applications.
Website or web application security has multiple aspects that need focus and work and one good way to start is by adding security headers.
Security headers for WordPress help you to provide another layer of security to mitigate attacks and protect from various security vulnerabilities.
In this blog post, we will guide you through different types of security headers and help you to add them to your WordPress site to make your site more secure.
If you use Patchstack you can easily enable the “Add security headers” option on the Patchstack hardening tab. (It only works with sites run by Apache (requires .htaccess).
HTTP Strict Transport Security (HSTS) allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol.
Example:
Strict-Transport-Security: {parameter1} ; {parameter2}
max-age
parameter will set the time, in seconds, for the browser to remember that this site is only to be accessed using HTTPS.
includeSubDomains
is an additional parameter that can be used to apply this rule to all of the site’s subdomains as well.
You can add an HSTS security header to a WordPress site by adding a few lines of code to Apache .htaccess file or to Nginx.conf file. You can see the snippets for both server types below.
<VirtualHost 192.168.1.1:443>
Header always set Strict-Transport-Security “max-age=31536000;
includeSubDomains”
</VirtualHost>
add_header Strict-Transport-Security max-age=31536000;
X-Frame-Options protects visitors against Clickjacking attacks. Using an iframe, the content of your site could be loaded inside another website.
This could be abused maliciously when visitors click on a link they believe to be harmless when actually they’re navigating inside your website. This can be highly dangerous when the user has previously logged in to a restricted area on your site.
Example:
X-Frame-Options: {parameter}
deny
parameter will completely deny rendering within the iframe.
sameorigin
parameter will deny rendering if origin mismatches.
allow-from: DOMAIN
parameter allows rendering if it is framed by a frame loaded from the specified domain
You can add an X-Frame-Options security header to your WordPress site by configuring the .htaccess file (Apache). With NGINX you need to edit Nginx.conf file.
Setting sameorigin is recommended.
<IfModule mod_headers.c>
Header always append X-Frame-Options SAMEORIGIN
</IfModule>
add_header X-Frame-Options "SAMEORIGIN" always;
X-XSS-Protection security header allows you to configure the XSS protection mechanism found in popular web browsers. As an example, this could prevent session cookie stealing with persistent XSS attacks when a logged-in visitor is visiting a page with an XSS payload.
Example:
X-XSS-Protection: {paremeter1}; {parameter2}
0
parameter disables the filter.
1
parameter enables the filter.
1; mode=block
enables the filter with the 1
parameter and additionally blocks the website to be rendered with mode=block
.
1; report=https://your-report-url/
enables the filter with the 1
parameter, then sanitizes the request and sends the report to the selected URL with report=
parameter.
You can add an X-XSS-Protection security header to your WordPress site by configuring the .htaccess file (Apache). With NGINX you need to edit nginx.conf file.
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>
add_header X-Xss-Protection "1; mode=block" always;
Setting the X-Content-Type-Options header will prevent the browser from interpreting files as something else than declared by the content type in the HTTP headers. It has a lot of configuration options and potential parameters, but the most common parameter used is nosniff
.
Example:
X-Content-Type-Options: nosniff
You can add the X-Content-Type-Options security header to your WordPress site by configuring the .htaccess file (Apache). With NGINX you need to edit nginx.conf file.
<IfModule mod_headers.c>
Header set X-Content-Type-Options nosniff
</IfModule>
add_header X-Content-Type-Options "nosniff" always;
Content Security Policy header helps you reduce XSS risks on modern browsers by declaring, which dynamic resources are allowed to load.
Similar to X-Content-Type-Options, the Content-Security-Policy header has a lot of configuration options and potential parameters, but at this point, we will mention the ones in the example (which are recommended for beginners).
Example:
Content-Security-Policy default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';
default-src
parameter is the default policy for loading content such as JavaScript, Images, CSS, Fonts, AJAX requests, Frames, HTML5 Media.
script-src
parameter Defines valid sources of JavaScript.
connect-src
parameter applies to XMLHttpRequest (AJAX), WebSocket or EventSource. If not allowed the browser emulates a 400 HTTP status code.
img-src
parameter defines valid sources of images.
style-src
parameter Defines valid sources of stylesheets.
You can add a Content-Security-Policy security header to your WordPress site by configuring the .htaccess file (Apache). With NGINX you need to edit nginx.conf file.
Header set Content-Security-Policy default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';
add_header Content-Security-Policy "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';";
If you use Patchstack you can easily enable the “Add security headers” option on the Patchstack hardening tab. (It only works with sites run by Apache (requires .htaccess).
You can add security headers automatically with Patchstack. Get started with Patchstack here.
Security headers for WordPress help you to provide another layer of security to mitigate attacks and protect from various security vulnerabilities.
HTTP Strict Transport Security (HSTS) allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol.
Try Patchstack now, cancel anytime, 30-day money-back guarantee.