问题
I understand that cross-origin, "simple" requests, like GET and POST have always been allowed (but you just can't view the response), and that PUT/DELETE are blocked, or preflighted if your browser supports CORS.
I understand that allowing a GET request to be sent is harmless, as long as the response is blocked, because GET requests should be safe/idempotent (if not, that's the developer's fault for not making their API ReSTful).
I also understand from this answer, that GET and POST are typical/intentional requests made by users, eg when typing something into the URL textbox or clicking a button to post a form.
But why would a browser allow a cross-origin POST request using xhr?
So what if the user can make intentional POST requests by clicking on a button to post a form? Allowing javascript to send a POST request is a recipe for disaster, any malicious page that loads could execute a cross-origin POST request behind the scenes.
Why didn't browsers prevent this from the beginning?
If they did, then now that CORS is around, POST requests could be preflighted just like PUT/DELETE and you'd have fewer xsrf attacks.
回答1:
Eliminating the ability to use POST would have drastically reduced the capabilities of web applications without providing a significant increase in security.
Without POST there would have been no way to request that another domain modify data. (Remember, this is before CORS offered a way to opt in to cross-domain requests.) That eliminates whole classes of useful web applications. (Or, more likely, web applications would have worked around this problem by abusing GET.)
And you wouldn't get much in return for this sacrifice. Any server that could be harmed by a cross-domain XHR POST would already have to have CSRF protections in place to deal with cross-domain attacks from a form POST. And such defenses (like requiring a special token) are equally effective against both.
来源：https://stackoverflow.com/questions/64769030/why-does-the-same-origin-policy-not-block-post-requests