WordPress Security Headers Without a Plugin: HSTS, CSP and Friends

Some of the strongest protection your site can have costs zero performance and needs zero plugins: HTTP response headers. They tell browsers how your site may be used — encrypt always, don’t let others frame it, don’t run injected scripts. Most WordPress sites ship almost none of them.

Here are the six that matter, what each one protects against, and exact configs.

The six headers

1. Strict-Transport-Security (HSTS)

Forces browsers to use HTTPS for your domain — even if a user types http://, even on hostile Wi-Fi that tries to downgrade the connection.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Only add after HTTPS works everywhere (see our HTTPS & mixed content guide) — HSTS is a promise browsers remember for a year.

2. X-Frame-Options / frame-ancestors

Stops other sites from embedding yours in an iframe — the basis of clickjacking (invisible frames over fake buttons).

X-Frame-Options: SAMEORIGIN

3. X-Content-Type-Options

Stops browsers from “sniffing” file types — which can turn an uploaded file into executable script.

X-Content-Type-Options: nosniff

One word, zero downside. There is no reason not to have this.

4. Referrer-Policy

Controls how much URL information leaks to sites you link to. Without it, third parties may see full URLs — including query parameters you’d rather keep private.

Referrer-Policy: strict-origin-when-cross-origin

5. Permissions-Policy

Declares which browser features (camera, microphone, geolocation) your pages may use — so injected third-party code can’t quietly request them.

Permissions-Policy: camera=(), microphone=(), geolocation=()

6. Content-Security-Policy (CSP)

The heavyweight: a whitelist of where scripts, styles and frames may load from. A good CSP neutralizes most XSS — relevant on WordPress, where cross-site scripting accounts for roughly half of disclosed vulnerabilities. It’s also the hardest to write, because every analytics tag and embed must be listed.

Start in report-only mode, watch the console, then enforce:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'

On a clean-coded site with two or three known script sources, a strict CSP takes an hour. On a 30-plugin site loading scripts from everywhere, it’s painful — one more hidden cost of plugin bloat.

Where to add them

Apache (.htaccess):

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

NGINX (server block):

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

No server access? PHP fallback (works, slightly less ideal than server-level):

add_action('send_headers', function () {
    header('X-Frame-Options: SAMEORIGIN');
    header('X-Content-Type-Options: nosniff');
    header('Referrer-Policy: strict-origin-when-cross-origin');
    header('Permissions-Policy: camera=(), microphone=(), geolocation=()');
});

Verify

Two minutes: run your domain through our Site Analyzer — it checks HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy and tells you exactly which are missing. Then re-run after deploying.

Headers won’t patch a vulnerable plugin — that’s what the hardening checklist is for. But they’re the rare security upgrade that’s free, fast, invisible to users and permanent. There’s no good reason your site should be missing them by next week.