Skip to main content
Header rules let you rewrite, add, or strip HTTP headers at the edge — without touching your origin. Use them for routing (Host), browser policy (CORS, security headers), and observability (request tagging).

Header types

Host header

Host Header

Host Header

Toggle Host Header on, then set: Set this when your origin uses virtual hosting or its TLS cert is for a name other than the distribution hostname.

CORS headers

CORS Headers

CORS Headers

Toggle CORS Headers on. Pick:
  • * — allow any origin (fine for fully public assets).
  • Specify Origin — allowlist a domain (e.g. https://app.yoursite.com). The CDN echoes that exact origin in Access-Control-Allow-Origin only when the request matches.
Don’t use * for any URL that requires credentials (cookies, Authorization header). Browsers block credentialed cross-origin requests against *. Use a specific origin.
Verify with curl:
Expected:

Request headers

Toggle Request Header on, click Add Header, then set name + value. The header is added to every origin fetch. Use cases:
  • TaggingX-Edge-Pop: <auto> for log correlation.
  • Auth forwarding — pin an Authorization: Bearer ... for a private origin.
  • RoutingX-Tenant: prod so a multi-tenant origin picks the right backend.

Response headers

Response Header

Response Header

Two actions:

Security header recipe

A reasonable baseline for static / SPA distributions: Verify:

Hide leaky headers

These leak origin software versions. Strip them at the edge.

Response cache headers

Add Cache-Control at the edge to override or supplement origin headers: For path-specific TTLs, prefer Cache rules — they affect the edge cache, while a Cache-Control response header instructs the browser.

Manage via API

See the CDN API reference for the canonical schema.

Troubleshooting