Essential goal of the same origin policy

Question

As I read, the same origin policy is to prevent the creation of scenarios with an origin in the (evil) domain A to request a (good) domain B - in other words, fake a request to a cross-site site.

While playing a little, I found out about the Access-Control-Allow-Origin and CORS headers, which, as I once understood, allows you to indicate a server from a good domain B that domain A is a valid origin (hence not evil). If this header is missing from the cross-domain response, the browser will not read anything from it, but it has already made a request anyway.

Now I somehow missed this point. If domain B has a web services API and cookie authentication at login, basically any operation can be performed on behalf of a poor user with an evil origin A, only the attacker will not see the answer.

What am I missing here? Where are my reasonings wrong?

Answer 1

As I read, the same origin policy is to prevent the creation of scenarios with an origin in the (evil) domain A to request a (good) domain B - in other words, fake a request to a cross-site site.

The same origin policy prevents the misreading of a domain name, port, or protocol from another source. It does not say anything about limiting requests made in the first place.

eg.

• http://www.example.com cannot read anything at http://www.example.edu
• https://www.example.com cannot read anything on http://www.example.com (except cookies, as the cookie policy of the same origin is different)
• http://www.example.com:8080 cannot read anything at http://www.example.com

A policy of the same origin does not prevent a request from being sent to another domain. This is only an answer that is read only. So that...

• http://www.example.com can transfer POST data to http://www.example.edu via AJAX or a form (even with credentials if third-party cookies are enabled in the browser)
• http://www.example.com could POST data to https://www.example.com via AJAX or form
• As for the same origin policy, https://www.example.com can send POST data to http://www.example.com , although the browser will most likely either block the request or alert the user as an HTTP content will be available through the HTTPS page. Definitely when through AJAX through the form the browser and settings will depend
• http://www.example.com can download an image from http://www.example.edu , however the image data will not be accessible using scripts

So, CORS does not weaken the security of what was already possible, it allows the domain to select in CORS and allows the other domain to read responses from it.

Answer 2

CORS does not prevent anything that was allowed before CORS was invented. He only indicates that sites allow queries that have always been denied before.

One site can always force a user agent to make requests to other sites from the very beginning of the Internet. Just think about hot links.

This is usually not the case for a site to allow cookie-only action because, as you point out, any site can make requests using cookies from other sites.

Typically, a site requires a request to contain something other than a cookie. For example, it might look for a CSRF token that should be read from a previous answer. Like site B, you need to use CORS to get this token.