Security HTTP Headers for WordPress

Discover the essential HTTP response headers that can enhance the security of your WordPress website.

At Wetopi we incorporate HTTP Security Headers in your WordPress server. This help you to restrict the actions that browsers can perform on your website and add an extra layer of security. Security headers make it much harder for attackers to exploit client-side vulnerabilities.

The basic Security HTTP Headers

At Wetopi, we deploy WordPress servers preconfigured by default with what we classify as basic security HTTP headers. These headers are widely accepted and do not compromise the standard functionalities of your WordPress site.

Protecting you from clickjacking

Typically, clickjacking is performed by displaying an invisible on top of the page the user sees. The user believes they are clicking the visible page but in fact, they are clicking an invisible element in the additional page transposed on top of it.

Clickjacking (classified as a user interface redress attack or UI redressing) is a malicious technique of tricking a user into clicking on something different from what the user perceives, …

https://en.wikipedia.org/wiki/Clickjacking

By default all Wetopi servers come with this HTTP Header configured. If not hosted with Wetopi, you can simply add this header to your Nginx server config with an add_header directive :

add_header X-Frame-Options SAMEORIGIN;

NOTE: by specifying SAMEORIGIN, we can still use the page within a frame if this frame, and its page have the same domain. By the other hand, if you don’t need to present information in frames you can replace the “SAMEORIGIN” by a “DENY”

Serving content always in HTTPS

The second basic Security HTTP Header we implement by default at Wetopi is known as the HSTS: HTTP Strict Transport Security.

By default, all Wetopi servers come with this HTTP Header configured. If your site is not hosted with Wetopi, you can easily add this header to your Nginx server configuration using this next add_header directive:

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

This header tells the browser to interact with your WordPress server using only HTTPS connections. The max-age specifies the time, in seconds, that the browser should remember to enforce HTTPS for the website. More information on Wikipedia.

Prevent exploiting MIME type inconsistencies to execute malicious code on a website

The purpose of this following HTTP header is to prevent attackers from executing malicious code on a website by preventing the browser from interpreting a file as a different MIME type than it actually is.

add_header X-Content-Type-Options nosniff;

This HTTP header is configured by default in all Wetopi hosted websites.

Read more about X-Content-Type-Options in Mozilla documentation.

With Wetopi you get FREE Development Servers, Brotli ready,
and finely tuned to serve WordPress at lighting speed.

Signup in 10 seconds and get your free wetopi account

Advanced Security HTTP Headers

In this section we will introduce the more recent and advanced security headers. At Wetopi we do not implement this headers by default due to the neeed to design their config according to the website requirements.

The Content Security Policy CSP

The Content Security Policy header is designed to help us mitigate attacks like Cross-Site Scripting (XSS) and data injection.

CSP headers enforce strict detailed rules on how our webiste loads and executes resources, protecting us against malware distribution, site defacement, and data theft.

Content Security Policy Headers defines a mechanism by which web developers can control the resources which a particular page can fetch or execute, as well as a number of security-relevant policy decisions.

Content Security Policy W3C Working Draft

The format of this Content-Security-Policy header is as follows:

Content-Security-Policy: directive parameter;

You can also define multiple directives in a single header by separating them with a semicolon:

Content-Security-Policy: directive parameter; directive parameter;

Additionally, you can include this header multiple times.

Content-Security-Policy: directive parameter; directive parameter;
Content-Security-Policy: directive parameter;

These multiple headers are cumulatively restrictive, meaning you can only further restrict the capabilities of the protected resource.

How to define the Content Security Policy header

Implementing the Content-Security-Policy (CSP) header involves several steps:

1. Understand CSP Directives

Familiarize yourself with CSP directives, which define the restrictions for resources on your web page. Common directives include default-src, script-src, style-src, img-src, font-src, connect-src, frame-src, media-src, object-src, and child-src.

Get a full view of the Content Security Policy (CSP)
Quick Reference Guide

https://content-security-policy.com/

2. Define Your CSP Policy

If you have a deep understanding of your site and its internal and external resources requirements. Then you can deploy Your CSP Policy by hand. Otherwise our recommendation is to use a Generator tool.

The CSP generator tool we currently use is the FREE Policy Generator by csper.io. You can install it in your browser (Chrome or Firefox) and lets you collect directives for your CSP while you browse your website.

3. Deploy it and Monitor Violations

Add it to your web server config and inspect the browser console to find the Policy Violations.

IMPORTANT: With WordPress sites, we recommend to have a double set of CSP rules. One for the Frontend and a second less strict for the Dashboard (the wp-admin)

Consider disabling Content Security Policy (CSP) rules specifically within the /wp-admin area. While this adjustment represents a security tradeoff, it can enhance compatibility and functionality within the WordPress Dashboard.

You can deploy the CSP header in your nginx WordPress server with the following add_header:

...

location /wp-admin {
    include  /var/www/conf/mime.types;
    try_files $uri $uri/ /index.php?$args;
}


location / {
    include  /var/www/conf/mime.types;

    add_header Content-Security-Policy "default-src 'self'; 
                                        script-src 'report-sample' 'self' 'unsafe-inline' 'unsafe-eval' https://unpkg.com/;
                                        style-src 'report-sample' 'self' 'unsafe-inline'; object-src 'none'; base-uri 'self';
                                        connect-src 'self' https://api.websitecarbon.com 
                                        frame-src 'self' https://www.youtube.com; 
                                        font-src 'self' data:;
                                        img-src 'self' data: https://s.w.org https://i.ytimg.com;
                                        manifest-src 'self'; 
                                        media-src 'self'; 
                                        worker-src 'self' blob:;";
    
    try_files $uri $uri/ /index.php?$args;
}

...

Once done, browse your site while you inspect the console in your Developer tools.

4. Fix the Security Policy and test again

Following the error description, fix the broken rule, and test again.

The Permissions Policy

Permissions Policy is similar to previous Content Security Policy but controls features instead of security behavior. Read more about this header at

The format of this Permissions-Policy header is as follows:

Permissions-Policy: directive=allowlist

Example when defined for an nginx server:

add_header Permissions-Policy "picture-in-picture=(), geolocation=(self https://wetopi.com), camera=*";

By specifying () for the origin list, the specified features will be disabled for all browsing contexts.

Read more about this directives in https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy#directives

The Referrer-Policy Header

This HTTP Header is intended to limit the amount of information that is sent when a website visitor clicks on a link.

This Referrer Policy can help us increase our privacy and security:

• By setting a stricter policy, websites can prevent sensitive information from being leaked through the Referer header when navigating from one page to another.
• In certain scenarios, such as when navigating from an HTTPS to an HTTP site, the Referer header might inadvertently expose sensitive information, such as authentication tokens or session identifiers.
• Prevent referrer spoofing attacks, where an attacker manipulates the “Referer” header to gain unauthorized access or deceive the server.

Read more about its syntax and at: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

We are techies passionate about WordPress. With wetopi, a Managed WordPress Hosting, we want to minimize the friction that every professional faces when working and hosting WordPress projects.

Not a wetopi user?

Free full performance servers for your development and test.
No credit card required.