A feed answers Access-Control-Allow-Headers with the wildcard, yet a caller sending Authorization still fails the check - why?

This is the failure that survives a careful configuration review, because the grant looks maximally permissive and the call still fails. Reading the wildcard precisely is the whole answer. ## When `*` is a wildcard at all Three grant fields accept `*`: - `Access-Control-Allow-Methods` - any method, rather than a named list; - `Access-Control-Allow-Headers` - any CORS-unsafe request header name the caller wants to send; - `Access-Control-Expose-Headers` - every response header name becomes readable by script. That reading applies to a request made **without credentials**. A request in credentialed mode reads these fields differently, and that difference is its own subject; what matters here is that *the wildcard's meaning is conditional*, so an answer that says `*` means everything, full stop, has already overstated it. ## The one name the wildcard never covers `Authorization` is defined as the **CORS non-wildcard request-header name**. The preflight check treats it separately: if the request carries `Authorization` and the granted header names do not contain `Authorization` explicitly, the check fails - and `*` does not count as containing it. A gauge feed offering authenticated write access therefore cannot lean on the wildcard: ```http OPTIONS /stations/42/readings HTTP/1.1 Host: gauges.example.org Origin: https://charts.example.net Access-Control-Request-Method: PUT Access-Control-Request-Headers: authorization,content-type HTTP/1.1 204 No Content Access-Control-Allow-Origin: https://charts.example.net Access-Control-Allow-Methods: PUT Access-Control-Allow-Headers: * ``` That exchange fails. Replacing the last line with `Access-Control-Allow-Headers: Authorization, Content-Type` makes it succeed, and nothing else in the exchange changes. The reason to carve it out is deliberate rather than accidental: a blanket `*` is nearly always written without any particular header in mind, and the one header most likely to carry a caller's credential should not be granted by an absent-minded default. Requiring it to be named makes the grant a decision. ## The corner the wildcard creates Because `*` is read as a wildcard in these fields, there is **no way to match a header or a method whose name is literally `*`**. The specification says so as an aside, and it is a fair question to be asked as a check on whether you have read the field or merely used it. In practice nothing is named `*`; the point is that the wildcard is a reading of the value, not an escape sequence with a literal form available. ## Diagnosing it The symptom is narrow and repeatable, and it separates this from every other CORS failure: 1. Anonymous callers of the same endpoint work. Authenticated ones do not. 2. The failure happens on the preflight, so the actual request is never issued and the server logs nothing for it. 3. The grant under review looks *more* permissive than a working one, which is why re-reading the configuration rarely finds it. | granted header field | caller sends Authorization | caller sends only a custom header | |---|---|---| | `*` | check fails | check passes | | `Authorization` | check passes | check fails | | `Authorization, X-Gauge-Station` | check passes | check passes | The habit that catches it is to compare what the caller actually asked for against what the answer actually named, rather than judging the answer's permissiveness in isolation. ## What this is not - **It is not about whether the header is safe to send.** The grant decides only whether the browser proceeds; the server still authenticates the caller on its own terms. - **It is not a carve-out on the response side.** `*` in `Access-Control-Expose-Headers` exposes every response header name for a non-credentialed request, with no equivalent exception - the exception is on the request-header grant. - **It is not an argument for the wildcard elsewhere.** A grant that names what it means is readable by the next person; a wildcard hides the fact that a decision was never made. State the rule the way it is checked - *`Authorization` must be named, because the wildcard does not include it* - and the rest of the field's behaviour follows.