同源策略的机制是什么以及为什么不预先发送简单的 post 请求

Question

1. What are the actual mechanisms of the same-origin-policy and how is it different to cors and
2. Why simple post requests are not pre-flighted since a post request can change state on a server.

To my understanding, the same origin policy has two main implementations, with complex requests a pre-flight request is initially sent to determine if the main request should be sent, and with simple requests, the browser just checking the access-control-allow-origin header on the response of a request.

Thus, with a simple post request, the access-control-allow-origin header of a response simply prevents javascript from reading the response, but the request still goes through to the server. Thus, a csrf attack could still go through with a simple post request.

As a side note, the above understanding is based on https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#cross-origin_network_access , 'writes are typically allowed' meaning a simple request can go through to a server, 'cross-origin reads are typically disallowed', without the request's origin header matching the access-control-allow origin, reads are disallowed by the browser. 'Some HTTP requests require preflight', complex requests require pre-flight. Me filling in the gaps of SOP's implementation is due to the my lack of understanding of the above linked docs in SOP's mechanism, and sources such as the 'Details' chapter of this link https://www.w3.org/Security/wiki/Same_Origin_Policy#:~:text=The%20same%2Dorigin%20policy%20restricts,origin%20PUT%20and%20DELETE%20requests . explaining a very similar process between the MDN Docs' explanation of CORS and SOP. Thus, my understanding of SOP vs CORS, is that prior to the invention of CORS, the pre-flight requests and access-control-allow headers were already implemented by SOP, but CORS is simply the changing of the access-control-allow headers within the responses.

Continuing with the my main post, this SO answer https://stackoverflow.com/a/39736697/19752150 attempts to explain why a post request is deemed simple and thus not subject to pre-flight.

But prior to CORS, browsers wouldn't allow you to do a cross-origin application/json POST at all, and so servers could assume they wouldn't receive them.

To my understanding, the history of csrf attacks goes something like, csrf attacks became a thing, browsers implemented the same-origin policy to stop csrf attacks, we wanted to be able to send cross-origin requests, CORS was made.

So this answer is confusing on two fronts. 1. 'browsers wouldn't allow you to do a cross-origin application/json POST at all'. the same-origin-policy makes it so that these requests are allowed to still get sent to the server, but the js just can't read the response. 2. The SO question asks why CORS doesn't make simple post requests send a pre-flight request, and thus this answer suggests that somewhere prior to CORS, browsers had some method of preventing cross-origin requests from being sent in its entirety, suggesting that SOP is the one responsible for this. But with what mechanism does SOP then do this? And building on my previously stated understanding of SOP, doesn't SOP only prevent reads by the js but still let the request go through successfully to the server for simply requests?

Thus, my main questions are still

1. what are the actual mechanisms of the same-origin-policy and what is its difference with cors and
2. why simple post requests are not pre-flighted since a post request can change state on a server. However, if at any point in the post I have a faulty misunderstanding, please correct me then as well.

Answer 1

Allow me to analyse your question step by step...

What are the actual mechanisms of the same-origin-policy and how is it different to cors

The Same-Origin Policy (SOP) is a relatively loose set of object-access and network-access restrictions that forms the basis of modern Web security. It revolves around the concept of Web origin .

Cross-Origin Resource Sharing (CORS) is a mechanism that a server can opt in so as to instruct browsers to selectively lift some of the SOP's network-access restrictions on both sending (requests) and reading (responses) for the server's clients; client here is to be understood as "Web content loaded in your browser that communicates with the server".

Don't conflate the SOP and CORS. No metaphor is perfect but, if the SOP is akin to a seatbelt, CORS is the button to unbuckle that seatbelt; and unbuckling a seatbelt never makes you more secure.

Why simple post requests are not pre-flighted since a post request can change state on a server.

CORS preflight is a mechanism that browsers use to check whether the server understand the CORS protocol. Introduce that mechanism was necessary in order to protect old servers that predate support for JavaScript-based cross-origin requests and CORS against cross-origin abuse. However, CORS preflight is not a general-purpose defence mechanism against cross-origin request forgery (traditionally called cross-site request forgery , or CSRF for short, but the technical meaning of site has since shifted, which now makes CSRF a problematic term). As you perceived correctly, simple POST requests can be forged and, if accepted by the server, can change the latter's state.

To my understanding, the same origin policy has two main implementations, with complex requests a pre-flight request is initially sent to determine if the main request should be sent, and with simple requests, the browser just checking the access-control-allow-origin header on the response of a request.

That's more or less correct, except for your conflation of the SOP with CORS.

Thus, with a simple post request, the access-control-allow-origin header of a response simply prevents javascript from reading the response, but the request still goes through to the server. Thus, a csrf attack could still go through with a simple post request.

Correct. Forging simple requests from another origin is still possible. More on that further down my answer.

[...] prior to the invention of CORS, the pre-flight requests and access-control-allow headers were already implemented by SOP, but CORS is simply the changing of the access-control-allow headers within the responses.

The SOP predates the CORS protocol and thus, CORS preflight. But you're right that all those Access-Control-* headers are part of the CORS protocol and didn't have any semantics beforehand.

[...] csrf attacks became a thing, browsers implemented the same-origin policy to stop csrf attacks, we wanted to be able to send cross-origin requests, CORS was made.

The SOP's main objective was to restrict cross-origin reading; for instance, to avoid http://attacker.com from sending authenticated requests to https://mybank.com and reading your account's balance from the response. The SOP could not have forbidden all cross-origin requests; otherwise, the Web would arguably be unusable.

1. 'browsers wouldn't allow you to do a cross-origin application/json POST at all'. the same-origin-policy makes it so that these requests are allowed to still get sent to the server, but the js just can't read the response.

The SOP places restrictions on the content-type of cross-origin requests. The essence of the MIME type must be one of the three values historically allowed by HTML forms:

• application/x-www-form-urlencoded
• text/plain
• multipart/form-data

Attempts to send a cross-origin request with Content-Type: application/json will cause the browser to trigger CORS preflight. The actual request won't even get sent unless the server agrees by replying "yes" to the preflight request automatically sent by the browser.

However, as a backend developer, you must be careful, because the advent of the Fetch API allowed things that were previously impossible. In particular, anyone can use fetch to craft a simple request (with a Content-Type of value text/plain , say) whose body contains well formatted JSON:

fetch("https://example.com", {method: "POST", body: JSON.stringify({"foo": "foo"})})

To fix ideas, if you open your browser's Console tab and paste the statement above, you should see something like the following request on the wire:

POST / HTTP/1.1
Host: example.com
Content-Length: 13
Sec-Ch-Ua: "Chromium";v="103", ".Not/A)Brand";v="99"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.134 Safari/537.36
Sec-Ch-Ua-Platform: "macOS"
Content-Type: text/plain;charset=UTF-8
Accept: */*
Origin: https://stackoverflow.com
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://stackoverflow.com/
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Connection: close

{"foo":"foo"}

Because the request remains simple (not preflighted ), the browser, in accordance with the rules of the SOP, has no objection to sending a request with such a body to the server. Actually, sending well-formatted JSON is also possible with a HTML form, but I leave that to you an exercise. For more about this overly permissive sending restrictions in general, see section 4 of Chen et al.'s 2018 USENIX paper .

Because cross-origin attackers can (and do ) exploit this, even if you expect requests containing JSON, you still need to implement defences against cross-origin abuse. See OWASP's cheat sheet on the topic .

For a great retrospective on the SOP (with a focus on object-access restrictions rather than on network-access ones, though), see LiveOverflow's recent video .