CORS defines how HTTP servers opt into sharing responses with browser scripts at other origins. Preflight and credential modes govern distinct steps; response sharing is not user authorization, and blocked reading does not always mean no request reached the server.
Requests can carry Origin, and response fields such as Access-Control-Allow-Origin opt into sharing. They govern script access without merging origins; a client cannot grant permission by adding that response field to its request.
CORS differs from status codes. A 403 response can be shared correctly, while a generated 200 can be unreadable because sharing fields mismatch. Server outcome and browser exposure are separate decisions.
For requests requiring preflight, the browser sends OPTIONS with the proposed method and relevant header names. Matching permission allows the subsequent request; not every cross-origin GET or other request needs that step.
Preflight permission can be cached to reduce round trips, but checks CORS conditions rather than business authorization. Some nonpreflighted requests can reach the server, so withholding sharing headers does not prevent every cross-site side effect.
With credentials mode include, sharing requires a specific allowed origin rather than a wildcard and Access-Control-Allow-Credentials: true. The rule follows mode, not merely whether this particular request happened to carry cookie bytes.
The specification’s cross-origin preflight does not carry credentials or authenticate the user. Tokens, sessions and resource permissions still apply. CORS is a browser sharing protocol, not a barrier preventing direct HTTP clients from contacting a service.