Cryonel

CORS Headers Reference

Cross-Origin Resource Sharing lets a server state which browser origins may access a response from JavaScript. It is a browser response-exposure policy, not a replacement for server authentication or authorization.

Request fields

HeaderSent by the browser
OriginThe requesting origin: scheme, host, and port.
Access-Control-Request-MethodThe method planned for the real request during preflight.
Access-Control-Request-HeadersNon-safelisted field names planned for the real request.

The browser constructs these fields. Application JavaScript should not attempt to forge them. A preflight is an OPTIONS request sent before a cross-origin request that uses a non-safelisted method, content type, or header.

Response policy fields

HeaderPurpose
Access-Control-Allow-OriginAllows one origin or, for non-credentialed access, a wildcard.
Access-Control-Allow-MethodsLists methods permitted by the preflight policy.
Access-Control-Allow-HeadersLists non-safelisted request fields permitted by preflight.
Access-Control-Allow-CredentialsAllows the browser to expose a credentialed response when true.
Access-Control-Expose-HeadersAllows JavaScript to read additional response fields.
Access-Control-Max-AgeControls how long a browser may cache a successful preflight.

Allowed origins

Match complete normalized origins from an explicit allowlist. An origin includes scheme and port, so HTTP and HTTPS are different. Do not reflect arbitrary Origin values. When policy varies by request origin, return the accepted origin and add Vary: Origin. Responses without an Origin request usually do not need a dynamic CORS field.

Credentials

Credentialed Fetch requests require client credential mode, an explicit allowed origin, and Access-Control-Allow-Credentials: true. A wildcard allowed origin cannot authorize credentialed response access. Cookie delivery also depends on Secure, SameSite, domain, path, and browser privacy rules. Bearer tokens still require server-side validation; CORS only controls browser exposure.

Methods and request headers

The preflight names the exact method and non-safelisted headers the browser plans to send. Return a narrow policy that includes them. Handle OPTIONS before normal endpoint authentication because the preflight is asking whether the later request may contain Authorization. The gateway, route, and application must all allow OPTIONS without redirecting to login or another host.

Exposed response headers

JavaScript can read safelisted response fields without additional exposure. To read fields such as a request ID, pagination cursor, or rate-limit metadata, list the needed names in Access-Control-Expose-Headers. Exposure does not make a secret safe; do not place credentials or sensitive internal data in browser-visible response fields.

Preflight caching

Access-Control-Max-Age can reduce OPTIONS traffic, subject to browser limits. Keep it short while policies are changing and increase it only when rollback behavior is understood. CDN caching of OPTIONS must account for Origin, requested method, and requested headers. A cache key that ignores them can apply the wrong policy.

Frequently Asked Questions

Is CORS authentication?

No. Authenticate and authorize on the server.

Can wildcard origin use credentials?

No. Return an explicit allowed origin.

Why add Vary: Origin?

It prevents shared-cache policy confusion between origins.

Related Tools and Guides