In the CORS protocol, what counts as a credential on a cross-origin request besides the session cookie?

## What the word means here A **credential**, in CORS, is client state the browser would attach on its own initiative because of who the user is — not something the calling code placed on the request. The specification lists exactly three kinds: 1. **HTTP cookies** — the everyday case, and the one every explanation reaches for first. 2. **TLS client certificates** — presented during the handshake that opened the connection. 3. **Authentication entries for HTTP authentication** — the browser's cache of credentials a user already supplied in answer to a challenge, replayed on later requests into the same protection space. What binds these three together is *ambience*. None of them is written by the page. Each is attached because the browser holds identity for that destination and decided, under its own rules, to use it. ## Why a tenant portal cares A property-management portal on one host calls a maintenance-request API on another. The tenant's session cookie is the obvious credential, and most teams stop there. But the same API may also be reached over a connection that presented a client certificate — used by the contractor-facing integration — and the same browser may hold an authentication entry for an internal administrative path. Every one of those makes a cross-origin request **credentialed**, and every one of them puts the response inside the scope of the same grant field. A team that hardens only the cookie path has hardened one of three. ## What is not a credential An `Authorization` header the page's own code sets is **not** a credential for CORS purposes, even though it plainly carries identity. The reason is the definition above: the code put it there, so it is not ambient. CORS therefore governs it as a **request header name** rather than as a credential: - it is the single **CORS non-wildcard request-header name**, meaning a `*` in `Access-Control-Allow-Headers` never covers it; - the server must name it explicitly in `Access-Control-Allow-Headers`; - adding it pushes an otherwise plain request into a preflight. So a call that authenticates with a bearer token in `Authorization` and no cookie is, in CORS terms, an **uncredentialed** request with one awkward header — a different configuration problem with different fields. | Kind of identity | How it reaches the server | What governs it in CORS | |---|---|---| | HTTP cookie | Browser attaches it from its own store | `Access-Control-Allow-Credentials` | | TLS client certificate | Offered during the handshake, not a header | `Access-Control-Allow-Credentials` | | HTTP authentication entry | Browser replays a cached answer to a challenge | `Access-Control-Allow-Credentials` | | `Authorization` set by script | The calling code writes it | `Access-Control-Allow-Headers`, and it forces a preflight | ## The credentials mode decides whether they travel A request carries one of three credentials modes: - **`"omit"`** — never attach any of the three. - **`"same-origin"`** — attach them only when the request is same-origin. This is the ordinary default for a cross-origin call, and it means nothing is attached. - **`"include"`** — attach them even cross-origin. Only this mode makes a request credentialed, and only this mode makes the server's `Access-Control-Allow-Credentials: true` necessary. The practical consequence is that **two conditions must both hold** before the personalised body ever exists: the calling code opted into `"include"`, *and* the browser's own cookie rules agreed to attach the cookie to a cross-site request. The grant field has nothing to say about either. It speaks only to what happens afterwards, on the reading side. ## Why one field, not three It is tempting to think each credential kind deserves its own grant. It does not, because the risk they create is identical: the response was computed for a signed-in user, and letting a second origin's script read it is the leak, regardless of which of the three identified that user. One field, one decision, one blast radius. ## What to carry away - Three credential kinds, not one. The certificate and the authentication cache are easy to forget precisely because they never appear as a header in a request dump. - Ambience is the test: *would the browser have attached this by itself?* - A token the code sets is not a credential; it is an unsafe request header name with its own rules. - The mode decides whether credentials are sent; the grant decides only whether script may read what comes back.