Access-Control-Allow-Headers: permitted request headers

A small set of request headers are safelisted and never trigger a preflight, but the safelisting of Content-Type is narrow: only the three form and text types qualify, so sending application/json is enough on its own to require a preflight. That surprises people who assumed the custom header they added was the cause.

The answer must cover every header the browser named in Access-Control-Request-Headers. Missing one fails the whole preflight, and the browser's console message names the offending header, which makes this one of the few CORS errors that tells you exactly what to fix.

The wildcard works for requests without credentials, with one carve out that catches people repeatedly: it does not cover Authorization. That header always has to be listed by name, so an API using bearer tokens cannot rely on the wildcard, whatever else its policy says.

Keep the list to headers you actually read. A generous list that names a dozen headers nobody sends is not more permissive in a useful way, it just makes the preflight response larger and hides which headers the endpoint genuinely expects from the next person who has to change it.

One more asymmetry catches people moving between the two allow lists: this one is compared case insensitively, while the method list is not. So Content-Type in your answer satisfies a request for content-type, but PATCH in lower case does not satisfy a request for PATCH. Writing both lists in their conventional casing avoids having to remember which rule applies where.