Hacker News Reader

Comment by TazeTSchnitzel | Hacker News Reader

Great.

Could somebody explain CORS to me? How is making the server you're contacting specify it wants to receive requests, in the response header, secure? The request has already been made!

View on HN

If the request is made by a web page from a different server it would ordinarily be rejected because of the same origin policy.

Using CORS allows you to specify which servers you can accept requests from unless of course you are using ; Access-Control-Allow-Origin: *

More info ; https://developer.mozilla.org/en-US/docs/HTTP_access_control http://en.wikipedia.org/wiki/Cross-origin_resource_sharing

Doesn't it keep a risk of XSS attacks though, since the CORS policy is only disovered AFTER the request is made?

The request is still made regardless, your JavaScript just won't be able to access the response without a CORS header set.

The request isn't actually made (at least not your request). The browser sends an OPTIONS request to get the CORS policy and then will block your request if its not allowed.

Edit: My above comment is slightly incorrect. If the request is "simple" it will be made and then you'll be blocked if it doesn't fit the CORS policy. If the request is not deemed "simple" (according to some rules you can look up in the spec) then the OPTIONS flow occurs.

Ah I see. I wondered if it dd some such thing. That's good to know.

Not really, no. If all it takes to exploit the remote service is to make the request (i.e., you don't need to be able to read the response data to exploit it), you can easily force a request by means other than XHR; an image tag is probably the most straightforward.

Also, strictly speaking, this class of attack is Cross-Site Request Forgery (CSRF), not Cross-Site Scripting (XSS).

Reply on news.ycombinator.com