I was writing an integration test leveraging v5.3.20 of Spring Framework's DefaultCorsProcessor implementation, and I found that as long as any single HTTP Request header in Access-Control-Request-Headers is allowed, it will consider the entire CORS preflight request valid (Source). The Access-Control-Allowed-Headers will include the intersection of those found in the Access-Control-Request-Headers and those allowed via CorsConfiguration (Source).

Their GitHub CONTRIBUTING.md says to ask questions on StackOverflow (Source), so here we are:

Should all HTTP Request headers in the Access-Control-Request-Headers CORS Preflight Request Header be allowed for a preflight to get a successful response, or is it fine if any of the listed HTTP Request headers are allowed?

I can't tell if this is a bug in Spring Framework or an implementation detail left up to CORS implementers. The WHATWG docs, which Mozilla and W3C point to as the authoritative source on the topic, do not provide an example or sufficient clarity.

CodePudding user response：

If the Access-Control-Allow-Headers in the preflight response are a strict subset of the Access-Control-Request-Headers in the preflight request, the client will not make the subsequent request. This server behaviour is fine, it is up to the client to draw the correct conclusion.

See step 7 of the CORS-preflight fetch specification.