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

In a nutshell, because of CORS, one domain cannot communicate with another domain. The domain being communicated with, will automatically reject requests, unless the server is setup to specifically allow the request to go through via setting CORS headers to white list specific domains or all domains (bad idea).





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...




Registration is open for Startup School 2019. Classes start July 22nd.

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

Search: