Website Security · Part 5 of 10

Essential Security Headers Explained.

Security headers are small instructions in an HTTP response that tell a visitor's browser how it should—and sometimes should not—handle your website.

What you'll learn: what HTTP security headers do, which ones matter most, why CSP deserves special care, where headers can be configured and how to test without breaking scripts, forms or embedded services.

What happens when a browser receives a page?

The browser does not receive only HTML. The server also sends HTTP response headers: metadata and instructions about the response. Some security headers tell the browser to insist on HTTPS, avoid guessing content types, limit who can frame the page, control what resources may load or reduce information sent in referrers.

WordPress / Server
HTTP response + security headers
Visitor's Browser

Headers do not replace server security, Cloudflare or WordPress hardening. They protect a different layer: how a capable browser handles content after the response arrives.

The headers worth understanding

Strict-Transport-Security (HSTS)Tells supporting browsers to use HTTPS for the site for a defined period. Powerful, but enable it only after HTTPS is reliably working everywhere it needs to.
Content-Security-Policy (CSP)Controls which sources are allowed to provide scripts, styles, images, frames and other resources. One of the most powerful—and easiest to break—headers.
X-Content-Type-Optionsnosniff tells browsers not to reinterpret certain resources as a different MIME type.
Frame protectionframe-ancestors in CSP, and the older X-Frame-Options mechanism, can limit who may embed pages in frames and reduce clickjacking risk.
Referrer-PolicyControls how much referrer information the browser sends when navigating to another resource or site.
Permissions-PolicyCan limit access to selected browser capabilities such as camera, microphone or geolocation when the site does not need them.

HSTS: simple idea, serious consequences

HSTS tells a browser that a domain should be contacted over HTTPS. That reduces opportunities for downgrade-style behaviour after the browser has learned the policy. But a long HSTS lifetime is not something to enable while HTTPS is half-configured.

If you include subdomains, every affected subdomain must be ready for HTTPS. HSTS preload is an additional commitment with its own requirements and removal process. Treat it as an architectural decision, not a score-chasing checkbox.

Content Security Policy: the header that needs testing

A CSP can restrict where scripts, styles, fonts, images, frames and connections may come from. That can significantly reduce the impact of some injection attacks. But modern WordPress sites often depend on page builders, analytics, maps, payment providers, video embeds, fonts, chat tools, CAPTCHA/Turnstile and other third-party resources.

A copied CSP that forgets one of those services may make a page look fine while silently breaking a form, map or checkout.

Page asks for script
Browser checks CSP
Allowed source? Load : Refuse

For a complex site, begin with an inventory of required sources. Consider report-only testing where appropriate, inspect browser console violations, then tighten deliberately. Avoid adding broad wildcards merely to make errors disappear.

Steve's Tip: A perfect security-header score is not worth a broken business website. I would rather deploy a carefully tested policy that fits the actual site than paste an aggressive configuration and discover later that contact forms or payments stopped working.

Where can headers be added?

Depending on the environment, headers may be configured at the web server, hosting control panel, reverse proxy/CDN or application layer. Apache sites often use server or .htaccess directives; Nginx uses server configuration; managed hosts and Cloudflare may offer header controls as well.

Choose one understandable source of truth where practical. Setting the same header in several layers can make troubleshooting confusing, especially when values conflict.

Example policy thinking—not a paste-and-forget recipe

Suppose a site loads its own scripts, a trusted analytics service, a payment frame and a form challenge. A CSP needs to account for the specific resource types and domains those services use. If the site later adds a booking platform, the policy may need revision.

That is why this guide explains the purpose rather than publishing one “universal” production CSP. There is no universal CSP for every WordPress website.

How to test security headers

✓ Inspect response headers in browser developer tools.
✓ Verify HTTPS and redirects before enabling a strong HSTS policy.
✓ Check the browser console for CSP violations.
✓ Test contact forms, checkout, booking, maps, video, analytics and embeds.
✓ Test logged-in WordPress administration where policies apply there.
✓ Use a reputable header-analysis tool as a second opinion, not as the only test.
✓ Re-test after adding new third-party services.

Common mistakes

Common problems include enabling HSTS before all required subdomains support HTTPS, deploying CSP directly to enforcement without observation, allowing * everywhere to silence errors, duplicating contradictory headers at Cloudflare and the server, and treating an online grade as proof the application works.

Common questions

Do security headers make WordPress secure?

No. They add browser-side protection. They do not patch plugins, secure administrator accounts or stop direct attacks on the server.

Should every site use exactly the same headers?

No. Several baseline headers are broadly useful, but CSP, Permissions Policy, framing requirements and HSTS scope depend on how the site works.

Can Cloudflare add security headers?

Cloudflare offers response-header capabilities in various products and plans, but server-side configuration is also common. Use the method that fits the environment and remains maintainable.

Important: Security headers can break legitimate website functionality. Back up configuration, document the previous state and test the complete visitor journey after changes.

Next: protect the administrator account

Part 6 moves from browser instructions to one of the most valuable targets on a WordPress site: administrator access.