4 ms·

If you don't return any CORS headers, all cross-origin requests will be blocked by default. If that's the behavior you want, there is no need to return any CORS

by kijin 9y ago

If you don't return any CORS headers, all cross-origin requests will be blocked by default. If that's the behavior you want, there is no need to return any CORS headers.

deathanatos 9y ago
> all cross-origin requests will be blocked by default "all" is a strong word. In the general case, you can make cross origin requests by doing <img src="http://api.the-latest-unicorn.io/v2/produce/rainbows"> or even <script src="..."> It's cross-origin, and it's a request, cookies will be sent with it, and if your GET requests have side-effects, you're going to have a bad time. You can even do POST requests, by making a <form> and auto-submitting it to the API with JavaScript. Of course, you're limited to certain MIME types, and notably not JSON. (And thank God for that.) Even if we assume that you only meant requests made by JavaScript via XHR, you can still make cross-origin requests. If you make an XHR request that looks like any of the above (specifically, if it meets the criteria for a "Simple Request"[1]), the browser will send it. It might not allow the JS that sent the request to view the response (if the response doesn't have the appropriate CORS headers), but the request still gets sent (because the response has to get received), and any side-effects can still happen. Thankfully, if you're writing a bog-standard JSON API, these usually don't apply … as long as you check your Content-Type header prior to decoding as JSON. (You are completely right, I think, that not returning any CORS headers is the most restricted — as far as CORS is concerned. My point being that sometimes, it's the response that gets blocked, not so much the request.) [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...
- kijin 9y ago
  You're right, it's the response not the request that gets blocked. What's even worse, modern browsers will make an OPTIONS "preflight request" if you try to make a non-simple cross-origin request with XHR, whether with or without CORS. The actual GET or POST request might be blocked, but OPTIONS always goes through. So if your webapp doesn't distinguish between GET and OPTIONS, and if your GET actions have side effects, you're in for a nasty surprise!

by kijin 9y ago

If you don't return any CORS headers, all cross-origin requests will be blocked by default. If that's the behavior you want, there is no need to return any CORS headers.

deathanatos 9y ago

> all cross-origin requests will be blocked by default "all" is a strong word. In the general case, you can make cross origin requests by doing <img src="http://api.the-latest-unicorn.io/v2/produce/rainbows"> or even <script src="..."> It's cross-origin, and it's a request, cookies will be sent with it, and if your GET requests have side-effects, you're going to have a bad time. You can even do POST requests, by making a <form> and auto-submitting it to the API with JavaScript. Of course, you're limited to certain MIME types, and notably not JSON. (And thank God for that.) Even if we assume that you only meant requests made by JavaScript via XHR, you can still make cross-origin requests. If you make an XHR request that looks like any of the above (specifically, if it meets the criteria for a "Simple Request"[1]), the browser will send it. It might not allow the JS that sent the request to view the response (if the response doesn't have the appropriate CORS headers), but the request still gets sent (because the response has to get received), and any side-effects can still happen. Thankfully, if you're writing a bog-standard JSON API, these usually don't apply … as long as you check your Content-Type header prior to decoding as JSON. (You are completely right, I think, that not returning any CORS headers is the most restricted — as far as CORS is concerned. My point being that sometimes, it's the response that gets blocked, not so much the request.) [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...

kijin 9y ago
You're right, it's the response not the request that gets blocked. What's even worse, modern browsers will make an OPTIONS "preflight request" if you try to make a non-simple cross-origin request with XHR, whether with or without CORS. The actual GET or POST request might be blocked, but OPTIONS always goes through. So if your webapp doesn't distinguish between GET and OPTIONS, and if your GET actions have side effects, you're in for a nasty surprise!