Security Headers for Cloudflare Pages and React Sites
How to use security headers, canonical metadata, and response verification to reduce common browser-side risks on static React deployments.
Key Points
- Security headers should be treated as deployment configuration, not just code comments.
- Cloudflare Pages supports static header rules that can be tested before release.
- Wildcard CORS is usually too broad for public static responses unless there is a specific cross-origin use case.
The baseline header set
A hardened React site should set browser behavior explicitly. The exact policy depends on the app, but the baseline usually includes content type protection, clickjacking protection, referrer control, permissions policy, and a carefully chosen content security policy.
Static hosts make this easy to forget because the app still renders without headers. The security work has to be verified at the HTTP response layer.
Cloudflare Pages considerations
- Keep header rules close to the repository when possible so changes are reviewed with code.
- Avoid dashboard-only changes unless they are documented, because they are harder for future maintainers to audit.
- Verify both www and apex domains if both are served.
- Check that redirects do not strip important headers from the final response.
CORS should be intentional
Access-Control-Allow-Origin: * is often copied into sites without a reason. For normal web pages, broad CORS usually does not help visitors and can make accidental data exposure easier if future endpoints are added under the same policy.
What to automate
- A test that rejects wildcard CORS in static header configuration.
- A build step that publishes sitemap and robots files.
- A preview check that confirms critical pages render and metadata is present.
- A live-response check after deployment for production domains.