Hacker News new | past | comments | ask | show | jobs | submit login

So, that is not my understanding, but I could definitely be wrong.

So, the one domain will attempt to communicate, the other domain will receive the request and return a response.

If the client doesn’t ‘like’ the response, it will error.




This only holds for indempotent requests (so in practice GET). Non-indempotent requests are "preflighted" and don't happen at all when the policy does not allow them.

So in fact CORS without any server-side configuration allows one to do arbitrary GET requests with cookies and authentication through XHR, but you could always just dynamically create IMG (as in the Zoom kludge) or SCRIPT (and the response will be executed in the page context, which is huge security risk as well as how JSON-P works) tag.

In other words: if your application does something security-sensitive (ie. write to anything other than log file) as part of GET request apart from producing the response, then your application is broken and same-origin policy nor CORS has nothing to do with that.


Not quite, POST requests with standard headers and one of the following content types are not preflighted:

application/x-www-form-urlencoded

multipart/form-data

text/plain

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simpl...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: