CORS (Cross-Origin Resource Sharing)

Cross-Origin Resource Sharing (CORS) is the mechanism by which a server tells a browser which other origins may read its responses. Browsers enforce the same-origin policy by default; CORS headers are how you relax it deliberately. An origin is the combination of scheme, host and port.

Why it matters

When a front end at https://app.example.com calls an API at https://api.example.com, the browser blocks the script from reading the response unless the API opts in. The request often still reaches the server, so CORS protects users' browsers, not your API. It is not authentication.

Example

A "non-simple" request, such as one with Authorization or JSON content type, triggers a preflight:

OPTIONS /v1/items HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: PUT

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, PUT
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 600
Vary: Origin

Common mistakes

• Returning Access-Control-Allow-Origin: * together with credentials. Browsers reject that combination.
• Reflecting any Origin value back without an allowlist, which effectively disables the protection.
• Omitting Vary: Origin when the header changes per origin, so a CDN caches the wrong response.
• Fixing the symptom in the front end. The error is resolved on the server (or proxy) that sends the response.

Related

• CSP
• Reverse proxy
• HTTP status code
• Guide: How to monitor API endpoints
• Tool: CORS checker

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.