Question

91

Is CORS a secure way to do cross-domain AJAX requests?

rated 0 times [ 98] [ 7] / answers: 1 / hits: 29532 / 14 Years ago, mon, january 31, 2011, 12:00:00

After reading about CORS (Cross-Origin Resource Sharing), I don't understand how it improves security. Cross-Domain AJAX communication is allowed if the correct ORIGIN header is sent. As an example, if I send

ORIGIN: http://example.com

The server checks if this domain is in the white list and, if it is, header:

Access-Control-Allow-Origin: [received url here]

is sent back, together with the response (This is the simple case, there are also prefighted requests, but the question is the same).

Is this really secure? If someone wants to receive the information, faking an ORIGIN headers seems like a really trivial task. Also the standard says that the policy is enforced in the browser, blocking the response if Access-Control-Allow-Origin is not correct. Obviously if anyone is trying to get that info, he will not use a standard browser to block it.

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

ethanc

Add To Favorites

Follow

Total Points: 57

Total Questions: 111

Total Answers: 111

Location: Vanuatu

Member since Fri, May 13, 2022

2 Years ago

answered 14 Years ago emiliano · Accepted Answer

You can't fake an Origin header with JavaScript in a web browser. CORS is designed to prevent that.

Outside of a web browser, it doesn't matter. It isn't designed to stop people from getting data that is available to the public. You can't expose it to the public without members of the public getting it.

It is designed so that given:

Alice, a person providing an API designed to be accessed via Ajax

Bob, a person with a web browser

Charlie, a third party running their own website

If Bob visits Charlie's website, then Charlie cannot send JS to Bob's browser so that it fetches data from Alice's website and sends it to Charlie.

The above situation becomes more important if Bob has a user account on Alice's website which allows him to do things like post comments, delete data, or see data that is not available to the general public — since without protection, Charlie's JS could tell Bob's browser to do that behind Bob's back (and then send the results to Charlie).

If you want to stop unauthorized people from seeing the data, then you need to protect it with passwords, SSL client certs or some other means of identity-based authentication/authorization.