How to set up HTTP security headers on Cloudflare without touching your code

HTTPS, WAF, firewalls, and vulnerability scanning get all the attention in website security, but one layer is easy to overlook: HTTP Security Headers.

Security headers are a group of HTTP response headers the server sends to the browser, telling it how site content should load, which behaviors to restrict, and which browser features should stay off, so common web attacks get blocked before they start. No website code needs to change, page content stays the same, and usually one configuration on the server or CDN layer covers the whole site.

For WordPress, WooCommerce, and corporate sites, configuring security headers through Cloudflare is simple, safe, and applies site-wide. This post explains what security headers are and what each common header does, then walks through the complete Cloudflare setup.

What are security headers

When a visitor opens a website, the browser and the server exchange HTTP traffic. Visit example.com, and the server responds with something like this:

HTTP/2 200 OK
Content-Type: text/html
Content-Security-Policy: ...
X-Frame-Options: ...

The extra lines in that response are HTTP headers. Security headers are the subset designed to tighten the browser’s security policy. They do not stop every attack by themselves; they make the browser follow stricter rules while loading the site.

Six security headers you should know

Here are the six most common security headers, each with a recommended configuration. The values are copy-ready, paste them into the Cloudflare rule as-is.

Strict-Transport-Security (HSTS)

Forces the browser to always use HTTPS. When a user types http://example.com, the browser rewrites it to https://example.com, preventing HTTP downgrade attacks (SSL Stripping).

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

max-age=31536000 means the policy stays valid for one year; includeSubDomains applies it to all subdomains.

X-Frame-Options

Stops your site from being embedded in a malicious iframe. An attacker can build a fake page on fake-login.com, load your site invisibly inside it, and trick users into clicking, which is Clickjacking.

X-Frame-Options: SAMEORIGIN

SAMEORIGIN means only same-origin pages may frame your site.

X-Content-Type-Options

Prevents the browser from guessing MIME types. An attacker may upload a malicious file disguised as an image, and if the browser decides the file type on its own, it can trigger a security risk.

X-Content-Type-Options: nosniff

nosniff tells the browser to process files strictly according to the declared Content-Type.

Referrer-Policy

Controls how much referrer information the browser sends when a user navigates to another site. Clicking an external link from example.com/products/product-a used to leak the full URL; strict-origin-when-cross-origin limits cross-origin navigation to the site origin only.

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

Content-Security-Policy (CSP)

Content-Security-Policy is the most important and most complex security header. It controls which scripts may run, which images may load, and which third-party resources the page can reach. For example, default-src ‘self’ means only the site’s own resources are allowed by default.

For WordPress sites, especially ones running Elementor, WooCommerce, Google Tag Manager, Google Analytics, WPML, or reCAPTCHA, a strict CSP needs real testing, or page assets stop loading. That is why many corporate sites start with upgrade-insecure-requests, which simply upgrades HTTP resources to HTTPS.

Content-Security-Policy: upgrade-insecure-requests

Permissions-Policy

Controls browser feature access, like the camera, microphone, and geolocation. A regular corporate site rarely needs any of these, so block them outright.

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

Why configure them in Cloudflare

When the site runs as user, Cloudflare CDN, server, WordPress, Cloudflare sits between the user and the server. Headers added at that middle layer are attached before the request reaches the browser, and the origin server does nothing.

Configuring security headers in Cloudflare has a few practical advantages:

• No WordPress files to edit, and no Nginx or Apache configuration to touch.
• Applies site-wide, so subdomains do not need separate handling.
• Config moves with the domain, so it survives a server migration.

Whether your site runs on Hostinger shared hosting or a VPS, security headers can be configured in one place at the Cloudflare layer, which is the least painful option for a corporate site.

Step 1: Enable Cloudflare managed security headers

Open the Cloudflare Dashboard, pick your domain (example.com), and go to Rules, then Settings, and find the HTTP Response Headers section.

First, enable the Remove X-Powered-By Headers option. It strips server-leaked information like X-Powered-By: PHP/8.1, so the site’s technical stack is not exposed at a glance.

Then enable Add Security Headers. Cloudflare automatically adds the common security headers, including Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy. Save when done.

The setup assumes your domain is already on Cloudflare. Why developers prefer hosting DNS on Cloudflare is a separate topic, covered in this post.

Step 2: Add a custom response header rule

Back on Rules, go to Overview, click Create rule in the top-right corner, and pick Modify Cloudflare Configurations and Behaviors-Response Header Transform Rule from the dropdown to create a new response header transform rule.

This is where people trip up: do not pick Request Header Transform Rules, the two directions are completely different.

Security headers belong on the Response side. Give the rule a name, like Security Headers, so it is easy to recognize later; set the match to All incoming requests for site-wide coverage, then choose Set Static and add two custom headers:

Header name: Strict-Transport-Security
Value: max-age=31536000; includeSubDomains

And:

Header name: Permissions-Policy
Value: camera=(), microphone=(), geolocation=()

HSTS and Permissions-Policy are not in Cloudflare’s managed list, so the custom rule fills the gap. Save the rule and you are done.

Step 3: Verify with SecurityHeaders.com

After configuring, open securityheaders.com and enter your site URL.

Check that all of these show green:

• Permissions-Policy
• Content-Security-Policy
• Strict-Transport-Security
• Referrer-Policy
• X-Content-Type-Options
• X-Frame-Options

If all six pass, your site’s baseline security header configuration is complete.

Notes

Do not put security headers in the Request Header. This is the most common mistake in Cloudflare. HSTS, CSP, and Permissions-Policy are read by the browser, not the server, so putting them in the wrong direction does nothing.

Do not jump straight to a strict CSP. WordPress relies on many third-party resources, and default-src ‘self’ right away can break page styles, disable the Elementor editor, or stop Google Analytics. Start with upgrade-insecure-requests, then tighten gradually and test.

Summary

Security headers are one of the cheapest, highest-value improvements in website security. The whole flow breaks down into three steps:

Start in the Cloudflare Dashboard under Rules, Settings, enable Remove X-Powered-By and Add Security Headers. Then in Rules, Overview, add HSTS and Permissions-Policy through a Response Header Transform Rule. Finally, check all six items on SecurityHeaders.com. No WordPress code changes, no impact on SEO, schema, caching, or site features, and it is the first hardening task worth doing after a corporate site goes live.

Once security is covered, site speed is the next thing worth working on, see 15 tricks to make your WordPress site fast.