Your API's redirect is eating the Authorization header

We shipped a bug last week where a valid API key arrived at our server as no key at all. The cause is a line in the fetch spec that most of us have read and none of us remember, and it will bite anyone whose API answers on both example.com and www.example.com.

Here is the whole thing, as it was before we fixed it. Our apex no longer redirects, so running this against us today no longer reproduces it — swap in any API of your own that answers on both hosts.

# apex, which 308'd to www
curl -s "https://example.com/v1/score/ip?ip=8.8.8.8" \
  -H "Authorization: Bearer $KEY" -L
# {"error":"Missing API key..."}

# www directly
curl -s "https://www.example.com/v1/score/ip?ip=8.8.8.8" \
  -H "Authorization: Bearer $KEY"
# {"error":"Invalid or revoked API key."}

The second error is the good one. "Invalid or revoked" means the key arrived and was judged. "Missing" means it never got there — and the only difference between the two calls is a redirect from the apex domain to www.

Why: when a redirect changes host, clients strip Authorization. It is in the fetch spec, it is in curl since 7.58, and it is in every browser. It is a good rule — following a redirect to an attacker-controlled host with your bearer token attached is how tokens leak — and it is invisible until it isn't.

What makes it nasty is the shape of the failure. X-Api-Key is a custom header and survives the hop. So our SDKs, which send X-Api-Key, were fine. Only Authorization: Bearer broke — which meant the people hitting it were the ones reading the docs and writing curl by hand, and the error they got said "missing API key" while they were looking straight at the key they had just pasted.

And it came back. We fixed this in July. It regressed in August because the redirect is a setting in a hosting dashboard, not a line in the repo — so no code review could catch it and no test was watching. That is the part worth taking away: a bug whose cause lives outside your codebase will come back, and the only defence is a test that asserts the behaviour from outside.

✗ the apex host does not redirect /v1 (a redirect strips the key)
    apex returned 308 -> https://www.example.com/v1/... ;
    a keyed request following this arrives unauthenticated

The fix, if you have this: serve your API on whichever host was asked for, and redirect only the pages. Machine surfaces — your API, your JS snippet, your OpenAPI file, .well-known — should not redirect at all. Canonicalise the HTML and leave the machines alone.

That is what we did, and the assertion above is now green. A page on the apex still 308s to www, so there is still one canonical URL in the index; /v1 and the other machine paths answer on whichever host you ask.

If you would rather not change your hosting: at minimum, say so in your 401. Ours now reads "check you called https://www.layercall.com" — because the developer hitting this has no way to guess, and the header they lost is not visible from where they are standing.