Menu
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.
762
Go to https://www.getpostman.com/docs/capture in your chrome browser. Click on interceptor extension and then choose add to chrome. Once it is added there is a new icon top right of both the browser and postman that looks like a traffic light. In postman click this and it turns green.
"Invalid CORS request" can mean that a request doesn't have an Origin header (so it's not a CORS request at all) or that it's a CORS request but: the Origin request header doesn't match any of the allowed origins.
The text of the error message will be something similar to the following: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://some-url-here.
to fix the error, you need to enable CORS on the server. The client expects to see CORS headers sent back in order to allow the request. It might even send a preflight request to make sure that the headers are there. You can enable CORS server side for one, multiple, or all domains hitting your server.
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
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.)
173
I just want to add to the Monsur's answer. There is one another behaviour(the one that is currently in use by S3):
To only send CORS response headers when they match the request's Origin. Otherwise, not send any CORS headers at all and let your browser, or any other client, decide for yourself.
At least this is how it works for me.
Also, when it comes to Java, it's common to send 403. That Java link is quite old, but the de-facto standard in Java, Spring, approach is the same. See my reference here.
30
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
