Documentation: Home / Security Features / Configuring Security Headers for WordPress

Configuring Security Headers for WordPress

Rogier Lankhorst
February 9, 2019
11:17 pm

While SSL is an important layer of security on your site, we additionally recommend adding several Security Headers to further strengthen your site’s security. You can quickly enable all of these Security Headers with the recommended values in the Really Simple SSL Pro interface (SSL & Security -> Settings -> Security Headers), or you can manually add the headers instead.

There are several configurations where security headers can’t be configured with the .htaccess file. This includes hosts who don’t support this in the .htaccess file or other servers than Apache, like NGINX, or load balanced configurations. Therefore, Really Simple SSL Pro configures the headers with PHP in a file called advanced-headers.php, located in the /wp-content/ folder.

One example of an important header is HSTS (HTTP Strict Transport Security), which prevents your website users to load a fake version of your website, created by a hacker. But there are more ways to break into a site. To make this as hard as possible, we recommend adding the below headers to your site.

HSTS

When this header is set on your domain, a browser will do all requests to your site over https from then on. So in the case where a hacker is redirecting this user to a fake domain.com, the browser remembers to use SSL because of the HSTS, so requests the secure site. But this doesn’t exist: no SSL certificate was authorized for this hacker’s fake site.

HSTS Preload

As HSTS is only enforced after the browser visits your site, this is a vulnerability: if the user hasn’t visited your site before, HSTS won’t be set, so the visitor can still request the site over http. There is a solution for this: the HSTS preload list. This is a list of HSTS domains, that is preloaded in browsers. If you’re on the list, the browser will know that it should only load your site over https, even before it ever requests your site.

But be careful with this feature: all subdomains (like sub.domain.com) will be forced over https as well, and removal from the preload list is very difficult, and might not propagate very fast. So even if you’re removed, browsers will likely still have your site in the list for months.

Content Security Policy:
Upgrade-Insecure-Requests

The Content Security Policy – Upgrade-Insecure-Requests header provides an additional method to force http:// requests on your own domain to https://. All http:// requests will be automatically upgraded to https:// when this header is enabled.

X-Content-Type-Options

This header will force the browser not to “guess” what kind of data is passed. If the extension is “.doc”, the browser should get a .doc file, not something else (a .exe). Otherwise the browser might be tricked into executing a script, while the user thinks he’s downloading an innocent file

X-XSS-Protection

The X-XSS-Protection security header was created to control the built-in protection against Reflected Cross-Site Scripting (XSS) attacks in web browsers and would stop pages from loading if a reflected cross-site scripting (XSS) attack is detected.

The problem with the X-XSS-Protection is that it introduces new possibilities for cross-site information leak attacks. The consensus among security researchers is that XSS Protection in browsers is best disabled and that the Content Security Policy Header (CSP) is used to mitigate XSS vulnerabilities.

Really Simple SSL Pro therefore recommends setting this header to the value “0” (to disable XSS filtering).

X-Frame-Options

X-Frame-Options prevents loading of the site in an iframe. The header can declare if it is allowed to load the current site in an iframe. This prevents clickjacking, by preventing the site to get secretly embedded in another site using an iframe.

When setting this header to SAMEORIGIN, it will block your site from showing your site in an iframe on other sites, but still allows the site to load in an iFrame from the same site. When using DENY, the site can not be loaded in an iFrame even if the domain matches the ‘current’ site/page.

Really Simple SSL will keep this header in sync with the Frame Ancestors header to ensure a compatible configuration between them.

Content Security Policy: Frame-Ancestors

The Frame Ancestors directive in CSP is similar to the X-Frame-Options header listed above, as it specifies the origins that are allowed to embed the current page.

These days, using a CSP with the frame-ancestors directive to control which origins are allowed to embed the site with embedding mechanisms such as iFrames, is generally preferred over X-Frame-Options, as the CSP offers more flexibility in specifying security policies.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors

Referrer Policy

Only sets a referrer when going from the same protocol and not when downgrading (HTTPS -> HTTP). This way a redirect will never redirect to a less secure protocol (http).

Content Security Policy

Read the instructions carefully first. When in reporting mode, CSP can slow down your site, as the reports are fired to your server, and saved using the CSP api. If you notice performance issues, please disable reporting only on low traffic moments, until you have gathered enough data to start enforcing.

With CSP you can define from which domains your website may load resources, like images, stylesheets, javascript files etc. This is one of the more advanced headers: because of the modular nature of WordPress, each plugin and theme can add their own resources, like Google Fonts. Also social services, like Facebook, Google Maps, etc, will load external resources. These will all need to be added to the “safe” list. To make this easy, Really Simple SSL has added a reporting mode, which will automatically log the requests that would be blocked. When you have run this a few days, you can check the detected list. If you see the resources is known and safe, you can add it to the list of safe resources. When you have done this with all reported items, you can enable the live mode.

Permissions Policy

Read the instructions carefully first.

The Permissions Policy header is a security header that controls which browser features can be used. Besides implementing these rules for your own content it can also prevent external iframes from using these browser features, making it a powerful header to secure your site.

The Permissions-Policy HTTP header replaces the existing Feature-Policy header for controlling delegation of permissions and powerful features. The header uses a structured syntax, and allows sites to more tightly restrict which origins can be granted access to features. This will be released in Really Simple SSL 4.1 before depracation.

Cross-Origin Policies

The Cross-Origin Policies security headers contain the following headers Cross-Origin Resource Sharing (CORS), Cross-Origin Resource Policy (CORP), Cross-Origin-Embedder-Policy (COEP) and Cross-Origin-Opener-Policy (COOP). For more information about these headers see our dedicated Cross-Origin Security Headers article.

Improve your security with Security Headers

In this article

Categories

Most popular