How to Add Strict Security Headers in WordPress (Without Server Access)

What are Security Headers?

Security headers are HTTP response headers sent by your server – They instruct the browser how to behave when handling your website’s content – particularly in ways that reduce common attacks (such as clickjacking, XSS, MIME sniffing, and downgrade attacks).

A security header doesn’t secure WordPress itself – but it adds an additional defensive client-side layer to your overall security by controlling how the client’s browser interacts with your site.

How They Work (on a Technical Level)

When someone visits your website, the server will respond with a status code (usually"200 OK"), response headers, and the page content.

Security headers are part of the response header block. They’ll look something like this:

HTTP/1.1 200 OK
Content-Security-Policy: default-src 'self';
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff

The client’s browser will read the security headers BEFORE rendering the page, and enforce the rules the headers define.

Common Security Headers (and What They Do)

Content-Security-Policy (CSP)

Controls which sources of scripts, styles, images, fonts, etc… are allowed to load on the website. This protects against cross-site scripting (XSS) attacks and other popular code-injections.

X-Frame-Options

Controls whether a website can be embedded inside an <iframe>, <frame>, <embed> or <object> element on another site. This header exists specifically to prevent clickjacking attacks which are becoming increasingly popular.

X-Content-Type-Options

By default, some browsers may attempt to"guess" a file’s type if it appears inconsistent with the server’s header. This default behaviour can lead to security risks, allowing malicious scripts disguised as a harmless file (eg. an uploaded .txt or .svg containing embedded JavaScript).

X-Content-Type-Options is an HTTP header that tells the browser not to"sniff" the MIME type and to strictly follow the declared Content-Type.

Strict-Transport-Security (HSTS)

This HTTP header tells browsers to always use HTTPS when connecting to your site – even if the user types http:// manually. Once a browser sees this header, it will automatically convert all HTTP requests into HTTPS for a defined period, preventing protocol downgrade attacks and reducing the risk of man-in-the-middle (MITM) interception.

How To Add Headers

The headers are best added to the relevant section within your hosting control panel, or added to the .htaccess file with the code below:

<IfModule mod_headers.c>
    Header set X-Content-Type-Options"nosniff"
    Header set X-Frame-Options"SAMEORIGIN"
    Header always set Strict-Transport-Security"max-age=31536000; includeSubDomains; preload"
    Header set Content-Security-Policy"default-src 'self'; script-src 'self'; style-src 'self' https://fonts.googleapis.com; img-src 'self' data:; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'self';"
</IfModule>

You can also add them via a PHP script in the website’s functions.php file or through a MU-plugin. This adds all headers safely:

add_action('send_headers', function() {
    header('X-Content-Type-Options: nosniff');
    header('X-Frame-Options: SAMEORIGIN');
    header('Strict-Transport-Security: max-age=31536000; includeSubDomains; preload');

    // Adjust 'self' and allowed domains as needed
    header("Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'self';");

});

DISCLAIMERS

• CSP should be tested on a staging environment – overly strict CSP rules can break scripts, styles or embedded content.
• For overly complicated setups such as routing through a CDN, the CSP may need adjustments.
• HSTS should only be enabled on sites which are fully-HTTPS – otherwise, users could be locked out.