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

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

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

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