Cloudflare Pages adds native custom header support

Cloudflare has announced that Pages now supports custom headers natively, meaning developers can define response headers directly in their project without relying on Workers. All you need is a _headers file in the build directory, with rules specified inside it.

/developer-docs/*
  X-Hiring: Looking for a job? We're hiring engineers
(https://www.cloudflare.com/careers/jobs)

Beyond site metadata

Headers control more than just how a page appears in search results. The _headers file lets you manage SEO, browser security protections, and cross-origin resource sharing policies directly from your Pages project.

Controlling search engine indexing

Every Pages deployment ships with a pages.dev subdomain, which makes it easy to preview recent changes before pushing them live. But those preview deployments can create duplicate content in search results, hurting your rankings. To keep that from happening, you can attach an X-Robots-Tag header pointing pages.dev deployments at search engine crawlers — such as letting Google know not to index a preview deployment.

https://:project.pages.dev/*
  X-Robots-Tag: noindex

Hardening browser security

A number of modern browser protections can be configured through headers alone. The _headers file supports commonly used security headers:

  • X-Frame-Options, to stop click-jacking by preventing your application from being rendered in an iframe
  • X-Content-Type-Options: nosniff, which prevents browsers from interpreting a response as anything other than the declared content type
  • Referrer-Policy, giving you control over how much referrer information is shared when visitors navigate away from your site
  • Permissions-Policy (formerly Feature-Policy), for disabling specific browser features to varying degrees
  • Content-Security-Policy, for granular content control including behavior similar to X-Frame-Options

For example, these headers can be scoped to protect an /app/* route:

/app/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: no-referrer
  Permissions-Policy: document-domain=()
  Content-Security-Policy: script-src 'self'; frame-ancestors 'none';

Cross-origin requests

CORS is a browser-level security measure that prevents one domain from triggering actions on another. Without it, a malicious site could make requests on behalf of visitors, such as attempting to initiate bank transfers. But legitimate cross-origin requests — like hotlinking to images or fetching static assets — are completely safe, since they involve no visitor session and no side effects.

By attaching CORS headers in the _headers file, you can allow any origin to access assets from your deployment using an asterisk:

/*
  Access-Control-Allow-Origin: *

Or lock things down so that only a staging subdomain can make requests:

https://:project.pages.dev/*
  Access-Control-Allow-Origin: https://staging.:project.pages.dev

How the matching engine works

To apply the right set of headers per request, Cloudflare built a new rule-matching engine backed by Workers. It supports splats and placeholders, and those matched values can be included directly in header values. The engine is modeled after the URLPattern specification that shipped in Chrome 95, though it doesn't yet implement every feature. Once URLPattern lands in the Workers runtime, Cloudflare expects to fully support the spec with no breaking migration changes.

New redirect capabilities

The same engine is also being applied to the _redirects file. Redirects can now use splats, placeholders, and custom status codes:

/blog/* https://blog.example.com/:splat 301
/products/:code/:name /products?name=:name&code=:code
/submit-form https://static-form.example.com/submit 307

Both custom headers and redirects are available today in Cloudflare Pages. Documentation for configuring them is already live, and Cloudflare is asking developers to share how they're using the new features on their Discord server.