What is the expected response to an invalid CORS r

Question

The CORS spec is silent on how servers should respond to invalid CORS requests. For example, if the request Origin is invalid, the CORS spec states: "terminate this set of steps. The request is outside the scope of this specification." There is similar language for other error cases, such as requesting invalid methods or headers.

What should the expected response be in the case of CORS errors? I understand that different servers may require different behavior. But I'm looking for a standard response or responses that could be acceptable if the server owner doesn't care.

Answer 1

I would expect that it would depend on the nature of the error, but I would expect some 4xx error such as 403 (if the request fails some required criteria) or 404 (if the method isn't available).

Answer 2

Yes, I realize I'm answering my own question, but here it goes anyway. I did some research into this and it seems like behavior falls into two camps:

1) Return an error if the CORS request is invalid. This is the route taken by the Java CORS filter project. This library returns

• 400 Bad Request for requests that don't conform to the spec
• 403 Forbidden for invalid origins or headers.
• 405 Method Not Allow for invalid methods

2) Return CORS headers in the response and let the browser sort out the access details. This seems to be the far more common approach, and is used by the APIs for Amazon S3, SoundCloud, FourSquare and Spotify (the latter two APIs benefit from only supporting simple CORS requests). In this case, the server doesn't do any error checking, and just returns the CORS headers for the supported origin, method and headers. The browser still makes the request, but if the CORS response headers don't match the user's request, the browser withholds the response from the user.

Each of these methods has their pros and cons. Method #1 is more closely aligned to the CORS spec, but provides no useful debugging information to the user.

Method #2 provides more insight into what the supported methods and headers are. It is also easier to implement, since the server is returning the same response headers regardless of the request headers. However this comes at the expense of actually executing the request on the server-side, even though the browser will block the response from the user. This may not be desirable for a method with side-effects, such as POST, PUT or DELETE and highlights the fact that CORS should not be used as an authentication mechanism.

(Note that my research above is by no means exhaustive. It was tough to see the true behavior for many APIs, since they either required auth, or blocked the request at a different level for some other error, such as an unsupported method.)