A preflight to your Go API fails once the SPA sends an Authorization header, though Allow-Origin and -Methods are set. Why?

## Reading the failure instead of guessing at it The report arrives from a frontend engineer: "CORS error after we added the auth header." The console message names a policy, not a cause, so the first move is to look at the two messages themselves — the preflight request and its response — either in the network panel with "OPTIONS" selected, or by reproducing it from a terminal: ``` OPTIONS /v1/orders HTTP/1.1 Origin: https://app.example.com Access-Control-Request-Method: GET Access-Control-Request-Headers: authorization ``` and the answer your Go middleware wrote: ``` HTTP/1.1 204 No Content Access-Control-Allow-Origin: https://app.example.com Access-Control-Allow-Methods: GET, POST, DELETE ``` The diagnosis is in the absence: the browser announced a header, and the response never acknowledged it. The rule the browser applies is all-or-nothing — *every* name in `Access-Control-Request-Headers` must be covered by `Access-Control-Allow-Headers`, or the preflight fails and the real request is never sent. That last part explains the second symptom people bring to this: the server logs show an OPTIONS and no GET, so it looks as if the frontend stopped calling. It did — the browser stopped it. ## Why adding a header changed anything at all The browser preflights a request when it is not one of the plainly safe ones. Sending an `Authorization` header, or a custom `X-...` header, or a `Content-Type` outside the small safe set, is enough to trigger it. So a request that previously went straight through with only `Access-Control-Allow-Origin` needed now needs a preflight to succeed first, and the preflight has requirements the simple response never had to meet. Nothing about the origin configuration changed; the class of request did. ## The two shapes of the fix in Go **A fixed list.** If you know what your API accepts, name it: ```go w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization, X-Request-Id") ``` This is the version to prefer. It is explicit, it is reviewable, and when the frontend adds a header the failure is a one-line change with a deliberate decision behind it. **Echoing the request.** If the list is genuinely open-ended: ```go if reqHdrs := r.Header.Get("Access-Control-Request-Headers"); reqHdrs != "" { w.Header().Set("Access-Control-Allow-Headers", reqHdrs) w.Header().Add("Vary", "Access-Control-Request-Headers") } ``` The browser sends the names comma-separated and lowercased, and the response may repeat them exactly as received — there is no need to canonicalise, and the comparison the browser makes is case-insensitive. The `Vary` line is the same discipline as with `Origin`: the response is now computed from a request header. The tradeoff is that this allows whatever the caller names, so it only belongs behind an origin allowlist that has already decided who may ask. ## What this response header does not do `Access-Control-Allow-Headers` is about the **request**. It says nothing about which response headers page JavaScript may read. That is `Access-Control-Expose-Headers`, and the confusion between them produces a distinct bug report: the frontend can see `X-Request-Id` in devtools but `response.headers.get(...)` returns null. The devtools panel shows what arrived on the wire; the JavaScript API shows only what was exposed. Adding the name to `Access-Control-Expose-Headers` on the real response fixes that one; adding it to `Allow-Headers` does nothing for it. ## Cutting the cost once it works Every preflight is a round trip the user pays for before the real call. `Access-Control-Max-Age` lets the browser reuse the answer for a period without asking again: ```go w.Header().Set("Access-Control-Max-Age", "600") ``` Browsers cap the value well below whatever large number you write, so treat it as a hint rather than a contract, and remember that a cached preflight answer means a policy change does not take effect for those clients immediately. ## The wider habit When a browser call fails and a server-side call to the same endpoint succeeds, the difference is almost always in the preflight, and the preflight is a plain HTTP exchange you can print. Compare the `Access-Control-Request-*` headers on the way in against the `Access-Control-Allow-*` headers on the way out, field by field: method against `Allow-Methods`, each requested header name against `Allow-Headers`, credentials against `Allow-Credentials`, and origin against `Allow-Origin`. Whichever pair does not line up is the bug, and the console text will not tell you which one it was.