Dubious purpose of the same origin policy

Question

As I read, the same origin policy is about preventing scripts with origin in (evil) domain A to make requests to (good) domain B - in other words cross-site request forgery.

Answer 1

CORS doesn't prevent anything that was allowed before CORS was invented. It only specifies a way for sites to allow requests that were previously always denied.

One site could always cause a user agent to make requests to other sites, since the beginning of the Web. Just think hotlinked images.

Typically, it's not correct for a site to authorize an action just based on a cookie, because, as you point out, any site can make requests using other sites' cookies.

A site will usually require that the request contain something other than the cookie. It might, for example, look for a CSRF token that must be read from a previous response. As site B, you'd need use CORS to obtain this token.

Answer 2

As I read, the same origin policy is about preventing scripts with origin in (evil) domain A to make requests to (good) domain B - in other words cross-site request forgery.

The Same Origin Policy prevents a mismatched domain, port or protocol combination reading from another origin. It says nothing about restricting requests from being made in the first place.

e.g.

• http://www.example.com cannot read anything on http://www.example.edu
• https://www.example.com cannot read anything on http://www.example.com (except cookies, as the Same Origin Policy for cookies is different)
• http://www.example.com:8080 cannot read anything on http://www.example.com

The Same Origin Policy does not prevent a request being made to another domain. It is only the response that is read only. So...

• http://www.example.com could POST data to http://www.example.edu via AJAX or form (even with credentials if 3rd party cookies are enabled in the browser)
• http://www.example.com could POST data to https://www.example.com via AJAX or form
• As far as the Same Origin Policy is concerned, https://www.example.com could POST data to http://www.example.com although the browser will more than likely either block the request or warn the user as HTTP content is accessed over a HTTPS page. Definitely when via AJAX, via form will depend on the browser and settings
• http://www.example.com could load an image from http://www.example.edu, however the image data will not be available via scripting

So CORS does not relax the security of what was already possible, it allows a domain to opt into CORS and allows another domain to read responses from it.