Question 1

What does a CORS policy actually control?

Accepted Answer

CORS (Cross-Origin Resource Sharing) is the browser mechanism that decides whether a script running on one origin can read responses from a different origin. The Access-Control-Allow-Origin response header is the centrepiece. Without that header, a browser blocks the response from the calling page even if the server returned data. With a permissive header, the server effectively says any caller can read the response. CORS is enforced by the browser, not by the server, so a misconfigured policy does not stop the request from being made; it only stops the calling page from seeing the response.

Question 2

Why is Access-Control-Allow-Origin: * dangerous on an authenticated endpoint?

Accepted Answer

A wildcard (*) means any origin can read the response. The browser still refuses to send credentials (cookies or HTTP authentication) when the origin is *, but if your endpoint serves authenticated data based on a bearer token in the Authorization header, the request goes through and any malicious origin gets the response. The defensible pattern is to echo the calling origin only when it appears on a server-side allowlist, set Access-Control-Allow-Credentials: true only when you actually need cookies, and add Vary: Origin so caches do not serve one tenant the response for another. Wildcard CORS belongs on truly public, unauthenticated endpoints (public APIs, fonts, static assets), not on anything that returns user-specific or tenant-specific data.

Question 3

What is a preflight request and when does it fire?

Accepted Answer

For requests that are not classified as simple by the Fetch standard, the browser sends an OPTIONS preflight first to ask whether the actual request is allowed. Preflight fires when the method is anything other than GET, HEAD, or POST; when the request carries a non-standard header such as Authorization or X-Custom-Token; when the Content-Type is something other than application/x-www-form-urlencoded, multipart/form-data, or text/plain; or when streaming uploads are used. The preflight reads Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Max-Age from the response, decides whether the actual request will be permitted, and then either sends it or aborts. The server must answer OPTIONS for every CORS-relevant route, not only the route that handles the actual verb.

Question 4

When should I send Access-Control-Allow-Credentials: true?

Accepted Answer

Only when the endpoint is intentionally designed to be called cross-origin with cookies or HTTP authentication. Setting Allow-Credentials: true forbids the wildcard origin and forbids the wildcard for Allow-Methods and Allow-Headers, so you must echo a specific origin from an allowlist and enumerate the methods and headers exactly. If your front-end is on the same eTLD+1 as your API and you carry session through SameSite cookies, you usually do not need cross-origin credentials at all. Turning on credentials cross-origin is a deliberate decision that should be paired with a tight origin allowlist and a Vary: Origin header.

Question 5

How do I handle multiple allowed origins?

Accepted Answer

The Access-Control-Allow-Origin header can only contain a single origin or *. If you need to support several origins (for example a marketing site, a customer dashboard, and a mobile web app on different subdomains), the server has to read the Origin request header, check it against an allowlist, and echo it back if it matches. Always add Vary: Origin so HTTP caches do not serve a response intended for one origin to a different one. Never naively echo the Origin header without an allowlist check; that is functionally equivalent to a wildcard with credentials and is the most common CORS misconfiguration in pentest reports.

Question 6

What is the maximum value I should set for Access-Control-Max-Age?

Accepted Answer

Access-Control-Max-Age tells the browser how long to cache the preflight result so it does not have to re-ask before every actual request. The Fetch standard does not bound the value, but browsers cap it. Chromium honours up to 7,200 seconds (two hours), Firefox up to 86,400 seconds (twenty-four hours). Setting a higher value is harmless syntactically but the browser silently clamps it. The trade-off is responsiveness to policy changes: a long max-age means clients keep using a stale preflight after you tighten the policy. A defensible default is 600 to 3,600 seconds (ten minutes to one hour) for most production APIs.

Question 7

Does CORS replace authentication or input validation?

Accepted Answer

No. CORS is a browser-side guard that controls which origins can read responses. It does not authenticate the caller, it does not validate the request body, and it does not prevent server-side attacks. Direct API clients (curl, Postman, native mobile apps, server-to-server calls) ignore CORS entirely because there is no browser involved. Authentication still has to be performed by the server, input still has to be validated, and CSRF mitigation (SameSite cookies, anti-CSRF tokens) is a separate layer. Treat CORS as the cross-origin read gate, not as an access control or input sanitiser.

Question 8

How does CORS interact with cookies and SameSite?

Accepted Answer

Cookies are not sent on cross-origin fetches by default in modern browsers because of SameSite=Lax. To send cookies cross-origin you have to mark the cookie SameSite=None and Secure, and the calling code has to use credentials: include (fetch) or withCredentials = true (XHR). The server must then respond with Access-Control-Allow-Credentials: true and a specific origin. Each step is opt-in deliberately; the chain exists so an authenticated session is not sent silently to an attacker origin. Most modern apps avoid SameSite=None entirely by colocating the front-end and API on the same eTLD+1 so cookies stay first-party.

Question 9

What CORS findings show up most often in a pentest?

Accepted Answer

Four patterns dominate. First, Access-Control-Allow-Origin: * on an authenticated endpoint that uses bearer tokens. Second, the server reflecting the Origin header without an allowlist (effectively a permissive CORS for any origin). Third, Allow-Credentials: true paired with a wildcard or with reflected origin (which browsers refuse, but the misconfiguration is still flagged because the server is signalling intent). Fourth, missing Vary: Origin on responses that vary by origin, which lets a shared cache serve one tenant the data of another. All four show up under OWASP Top 10 A05 (Security Misconfiguration) and are common findings in API security tests.

Question 10

Should I configure CORS at the application or at the gateway?

Accepted Answer

It depends on which layer owns the response. If your API serves content directly through an application server, CORS belongs at the application so it can short-circuit OPTIONS preflight requests and respond consistently with the actual route. If you front the API with a gateway (nginx, Cloudflare, AWS API Gateway, Kong), the gateway can centralise CORS so policies are uniform across services. The pitfall with gateway-only CORS is preflight handling: if the application also responds to OPTIONS, you can end up with duplicate or conflicting headers. Pick one owner per route and enforce it as a deployment rule.

Header	What it does
Access-Control-Allow-Origin	Which origin is allowed to read the response. A single origin or `*`. Cannot be a list. Echo from a server-side allowlist for multi-origin support.
Access-Control-Allow-Methods	Methods the actual request is permitted to use. Read by the preflight. Include OPTIONS so the preflight itself is allowed.
Access-Control-Allow-Headers	Request headers the actual call may send. Common entries: `Authorization`, `Content-Type`, custom tenant or trace headers.
Access-Control-Expose-Headers	Response headers the calling page can read via JavaScript. Without this, scripts only see the CORS-safelisted defaults.
Access-Control-Allow-Credentials	When `true`, cookies and HTTP auth are permitted cross-origin. Forbids wildcard origin and forbids wildcard Allow-Methods or Allow-Headers.
Access-Control-Max-Age	How long the browser caches the preflight response. Chromium caps at 7,200; Firefox at 86,400. Anything above is silently clamped.
Vary: Origin	Tells caches the response varies by Origin. Set it whenever you echo the request Origin from an allowlist.

Header	What it does
Access-Control-Allow-Origin	Which origin is allowed to read the response. A single origin or `*`. Cannot be a list. Echo from a server-side allowlist for multi-origin support.
Access-Control-Allow-Methods	Methods the actual request is permitted to use. Read by the preflight. Include OPTIONS so the preflight itself is allowed.
Access-Control-Allow-Headers	Request headers the actual call may send. Common entries: `Authorization`, `Content-Type`, custom tenant or trace headers.
Access-Control-Expose-Headers	Response headers the calling page can read via JavaScript. Without this, scripts only see the CORS-safelisted defaults.
Access-Control-Allow-Credentials	When `true`, cookies and HTTP auth are permitted cross-origin. Forbids wildcard origin and forbids wildcard Allow-Methods or Allow-Headers.
Access-Control-Max-Age	How long the browser caches the preflight response. Chromium caps at 7,200; Firefox at 86,400. Anything above is silently clamped.
Vary: Origin	Tells caches the response varies by Origin. Set it whenever you echo the request Origin from an allowlist.

CORS Policy Generatorbuild a defensible Access-Control header set

Origin policy

Allowed methods

Headers

Credentials and caching

Generated headers

Server snippets

How to roll out a CORS policy without breaking clients

CORS header reference

Three policies to start from

Public, unauthenticated API

Authenticated SPA on a different origin

Cookie-authenticated cross-origin

Where CORS fits in a pentest finding

Related tools and resources

Frequently asked questions

What does a CORS policy actually control?

Why is Access-Control-Allow-Origin: * dangerous on authenticated endpoints?

When does the browser send a preflight OPTIONS request?

How do I support multiple allowed origins?

When should I send Access-Control-Allow-Credentials: true?

Does CORS replace authentication?

Related features

Vulnerability scanning tools that map your attack surface

Vulnerability management software that tracks every finding

AI-powered reports in seconds, not days

API security testing

Security testing for web applications

Cyber security assessments

Want to verify the policy after you ship it?

Origin policy

Allowed methods

Headers

Credentials and caching

Generated headers

Server snippets

How to roll out a CORS policy without breaking clients

CORS header reference

Three policies to start from

Public, unauthenticated API

Authenticated SPA on a different origin

Cookie-authenticated cross-origin

Where CORS fits in a pentest finding

Related tools and resources

Frequently asked questions

What does a CORS policy actually control?

Why is Access-Control-Allow-Origin: * dangerous on authenticated endpoints?

When does the browser send a preflight OPTIONS request?

How do I support multiple allowed origins?

When should I send Access-Control-Allow-Credentials: true?

Does CORS replace authentication?

CORS Policy Generator
build a defensible Access-Control header set