Securing your website with WordPress security headers is a crucial step towards safeguarding your online presence. These headers offer a robust defense mechanism, fortifying your web applications against potential threats. The best part about them is they don´t require any changes of your codebase. With a plethora of options available for enhancing website security, security headers emerge as a straightforward yet highly effective starting point.
The Purpose Of HTTP Security Headers
HTTP security headers protect your site against malicious intruders, and they’re an extra layer of security that you won’t find difficult to set up, even if you weren’t blessed with much in the way of technical ability. There are a few different examples of these to consider, and we’re going to take a look at each one and explore how to add them to your WordPress site to make it more secure.
WordPress HTTP Security Headers To Consider
HTTP security headers help to keep web browsers safe from would-be attackers. Here are some of the kinds of HTTP response headers you might encounter in your quest for security.
X-Frame-Options
This keeps visitors safe from clickjacking attacks, where the content of your website could be loaded inside another site using iframe. When a visitor clicks on a link that they think is safe they could be navigating inside your website instead, and this could be very hazardous if the user had already logged in to one of your sites restricted areas.
The deny parameter stops any rendering of the iframe.
X-Frame-Options: DENY
And allow-from mydomain permits rendering if it’s framed by one that’s been loaded from a stipulated domain
X-Frame-Options: ALLOW-FROM https://www.plesk.com
The sameorigin parameter looks for an origin mismatch and if it finds one will deny rendering.
X-Frame-Options: SAMEORIGIN
How To Add X-Frame-Options Security Header To a WordPress Site
The X-Frame-Options security header can be added to your WordPress site via the .htaccess file for Apache and with the nginx.conf file in NGINX.
Apache
<IfModule mod_headers.c>
Header always append X-Frame-Options SAMEORIGIN
</IfModule>
NGINX
add_header X-Frame-Options "SAMEORIGIN" always;
HSTS – HTTP Strict Transport Security
HTTP Strict Transport Security is used when you want a web server to state that a web browser (or another user agent that is compliant) should only use secure HTTPS connections to interact with it and to never use HTTP, a protocol which is not so secure. HSTS is an IETF standards track protocol. It is specified in RFC 6797 after being approved years ago, in 2012.
includeSubDomains allows a rule to be applied to all of a site’s subdomains.
max-age lets the browser know how long it’s allowed to spend accessing a site via HTTPS.
Strict-Transport-Security: max-age=10886400; includeSubDomains
How To Add HTTP Strict Transport Security Header to WordPress
You can add the HSTS security header to a WordPress site using the code listed below to Apache’s .htaccess file or to the nginx.conf file:
Apache
<VirtualHost 88.10.194.81:443>
Header always set Strict-Transport-Security "max-age=10886400; includeSubDomains"
</VirtualHost>
NGINX
add_header Strict-Transport-Security max-age=10886400;
X-XSS-Protection
The X-XSS-Protection security header lets you configure the XSS protection system that you will find in many modern web-browsers. For instance, this could stop persistent XSS attacks from stealing cookies when a visitor who has logged in visits a page that contains an XSS element.
1 parameter turns the filter on.
0 parameter turns the filter off.
1; mode=block turns the filter on with the 1 parameter and also blocks the website that’s going to be rendered using mode=block.
1; report=https://thebesturlyoueverhad.com/ turns the filter on with the 1 parameter, then any illegal characters are removed from the request and the report is then forwarded to the chosen URL using the report= parameter.
How To Add X-XSS-Protection Security Header to WordPress Site
An X-XSS-Protection security header can be added to your WordPress site using the .htaccess file for Apache or the nginx.conf file in NGINX.
Apache
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>
NGINX
add_header X-Xss-Protection "1; mode=block" always;
Content-Security-Policy
The content security policy header can help you to reduce XSS risks on modern browsers by specifying which dynamic resources are permitted to load.
In a similar way to X-Content-Type-Options, the Content-Security-Policy header offers you a lot of different ways to configure it. For now, we’ll point out the ones in the example as they´re most accessible for beginners.
default-src specifies the standard policy for loading content like AJAX requests, frames, HTML5, images, js, css, fonts, and Media.
script-src defines what count as legitimate JavaScript sources.
connect-src applies to WebSocket, XMLHttpRequest (AJAX), EventSource. If not permitted the browser will emulate a 400 HTTP status code.
img-src defines bona fide image sources.
style-src defines authentic stylesheet sources.
Adding a Content Security Policy Security Header
You can add a Content-Security-Policy security header to a WordPress site using the .htaccess file for Apache and using the nginx.conf file in NGINX.
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';";
X-Content-Type-Options
Set the X-Content-Type-Options header to stop the browser from interpreting files as anything other than what’s been declared as the content type in the HTTP headers. It’s got many configuration options and lots of potential parameters, but the one that you will find being used most often is called nosniff
X-Content-Type-Options: nosniff
Adding an X-Content-Type-Options Security Header
You can add the X-Content-Type-Options security header to your WordPress via the .htaccess file for Apache and with the nginx.conf file in NGINX.
Apache
<IfModule mod_headers.c>
Header set X-Content-Type-Options nosniff
</IfModule>
NGINX
add_header X-Content-Type-Options "nosniff" always;
How To Add HTTP Security Headers If You Have Plesk?
Plesk is one of the most popular hosting platforms worldwide, it lets you build, secure, run websites and web apps. If your server is managed by Plesk, you have numerous options on how to adjust the HTTP security headers of your WordPress website. Here is the easiest one:
- Log into your Plesk hosting control panel via https://myserver.com:8443, where myserver.com is the domain name assigned to your server
- Click on ‘Domains’ section in the sidebar and choose the the website you want to add HTTP security headers.
- On the next page, you will see a variety of features – click on ‘Apache and nginx Settings’.
- Here you´ll be able to add Apache or NGINX headers into corresponding field with directives – ‘Additional Apache directives’ or ‘Additional nginx directives’.
- After adding directives, save your adjustments by clicking ‘Apply’ button.
Conclusion:
To sum up, adding WordPress security headers is crucial for safeguarding your website. This article was intended to simplify the process, making it easy for anyone to enhance their site’s security without technical expertise. By leveraging Plesk’s intuitive interface, you can effortlessly optimize your WordPress site’s security and ensure a safer online environment for both yourself, and for your visitors
with
4 Comments
Thank you!
Hi Elvis!
Is ‘always’ set correct?
Sometimes it is used, sometimes it is not used.
For example used on Apache but not on NGINX:
Apache
Header always set Strict-Transport-Security “max-age=10886400; includeSubDomains”
NGINX
add_header Strict-Transport-Security max-age=10886400;
Hi there,
The standard requires sending this header always, except when the request is made to plain HTTP. This means an HSTS Host returns the “Strict-Transport-Security” HTTP response header field in its HTTP response messages sent over secure transport. An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport. ‘Always’ means that the header will be sent even if the HTTP status code is 4xx, or 5xx. So arguably, it should be set to always in the HTTPS blocks and not be set in HTTP blocks at all. Hopefully, that can help. 🙂
Thanks for the reply Louis 🙂