Cross-origin read permission
Cross-Origin Resource Sharing is part of the Fetch standard. A server uses response headers to tell a browser which origins may read a cross-origin response and whether credentials are allowed. CORS relaxes selected same-origin read restrictions. It is not an authentication protocol and does not stop a non-browser client from sending a request.
Simple and preflighted requests
Some cross-origin requests use methods, headers, and content types that a browser can send without a preflight. Other requests first send an OPTIONS preflight with the intended method and header names. The server answers whether that origin, method, and header set is allowed.
The actual endpoint must still authenticate the caller, authorize the resource and action, validate input, and protect state changes from CSRF. A successful preflight does not grant application permission. A failed preflight is a browser-side read control, not a server-side security boundary against direct clients.
Narrow configuration
Return an exact allowed origin from a fixed server-side policy. Parse and compare the complete scheme, host, and port. Do not accept an origin because its string contains or ends with a trusted name. Do not reflect an arbitrary request origin.
Use credentialed CORS only when the browser feature requires it. A wildcard origin cannot safely stand for every credentialed caller. Limit allowed methods and request headers. Expose only response headers the client needs. Include Origin in cache variation when the response depends on origin and the cache does not already handle it.
Failure and residual risk
A trusted origin can be compromised through XSS, unsafe third-party script, or host takeover. An overly broad subdomain rule can grant that origin access. CORS does not prevent CSRF for requests that the browser can send. It does not protect data returned through JSONP, an open redirect, a public endpoint, or another server-side integration.
Pomerium boundary
Pomerium can authenticate and authorize a protected route. The upstream application decides which browser origins may read its responses and must return suitable CORS headers. Route policy does not replace application object authorization or CSRF protection. Operators must also ensure that preflight requests reach the component that owns the CORS decision.
Evaluation checklist
- Which exact browser origins need cross-origin read access, and for which resources?
- Does the server compare the complete parsed origin against a fixed policy?
- Are credentials, methods, headers, exposed response headers, and cache variation narrowly configured?
- Does the actual endpoint repeat authentication, object authorization, input validation, and CSRF controls?
- Can a trusted subdomain be registered, taken over, or compromised by unsafe script?
- Do tests cover simple requests, preflighted requests, null origin, redirects, cache behavior, and direct non-browser clients?
