Add security headers with a plan for your site
Review response headers, understand which controls fit the application, and test policy changes before enforcing them.
For your setup.
Choose your platform. A report may suggest one from source or delivery hints; confirm it matches the website you control.
Merge the relevant change into your existing configuration. These examples do not inspect your code or apply changes automatically. Test on a preview, then check the live response.
Set headers on Workers Static Assets
Cloudflare detection does not prove this site uses Workers Static Assets. This _headers rule applies to static assets only; it does not configure dynamically generated Worker responses.
# Static asset rule in _headers
/*
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-originVerify: Confirm this deployment uses Workers Static Assets. Test a static asset and a dynamic HTML route separately; the latter requires its own response-header handling.
Cloudflare Workers: static asset headers ↗Wrap an existing Worker response with headers
For dynamically generated responses, use this helper around the Response your existing Worker already creates. It is a wrapper pattern, not a complete replacement application; call it from the existing fetch handler.
function withSecurityHeaders(response) {
const headers = new Headers(response.headers);
headers.set('X-Content-Type-Options', 'nosniff');
headers.set('Referrer-Policy', 'strict-origin-when-cross-origin');
return new Response(response.body, {
status: response.status,
statusText: response.statusText,
headers,
});
}Verify: In the existing fetch handler, pass its generated Response through this helper. Test dynamic HTML and errors, and check that the response body, status, status text, and existing headers remain correct.
Cloudflare Workers: Fetch handler ↗Why this matters
Response headers can tell browsers how to handle content and features. Their value depends on a policy that matches the site’s resources and deployment; a header’s presence alone does not prove that the policy is strong or correctly applied.
Inventory the current response
Check the final HTTPS response for Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Confirm whether headers differ by route, redirect, or CDN edge.
Develop CSP from actual dependencies
List scripts, styles, fonts, images, frames, connections, and any inline code the site uses. Build a restrictive policy for that inventory rather than copying a generic allowlist. A policy that blocks legitimate resources can break the site.
Test before enforcing
Where supported by your delivery stack, deploy a Content-Security-Policy-Report-Only policy and review violations. Fix the dependency or refine the policy, then move to enforcement deliberately. Report-only policy does not itself block resources.
Roll out transport controls cautiously
Serve the whole site over HTTPS before enabling HSTS. Add `includeSubDomains` only if every covered subdomain is ready for HTTPS; preload is a separate commitment with removal delays. Choose other browser controls based on actual features and compatibility.
For your setup
Cloudflare
Response Header Transform Rules can set headers at the edge, but confirm that the active zone, rule order, and route scope match the deployed hostname. Check the final public response rather than relying only on dashboard configuration.
Next.js
Headers can be configured in the framework or hosting layer, but proxies may replace or append them. Test both direct and deployed responses and avoid duplicate CSP policies with unexpected cumulative restrictions.
Check your work
- Inspect the final response headers over HTTPS on representative routes.
- Test CSP in report-only mode and review violations before enforcing.
- Check all subdomains before adding HSTS includeSubDomains or preload.
- Test login, payments, embeds, fonts, analytics choices, and other site features after rollout.