为什么同源策略不阻止 POST 请求？ [复制]答案

【问题标题】：Why does the Same Origin Policy not block POST requests? [duplicate]为什么同源策略不阻止 POST 请求？ [复制]
【发布时间】：2021-02-22 09:34:21
【问题描述】：

我了解，GET 和 POST 等跨域“简单”请求始终被允许（但您无法查看响应），并且 PUT/DELETE 被阻止，或者如果您的浏览器支持 CORS，则预检.

我了解允许发送 GET 请求是无害的，只要响应被阻止，因为 GET 请求应该是安全/幂等的（如果不是，那是开发人员的错他们的 API ReSTful)。

我还从answer 了解到，GET 和 POST 是用户发出的典型/有意请求，例如在 URL 文本框中输入内容或单击按钮发布表单时。

但是为什么浏览器会允许使用 xhr 的跨域 POST 请求呢？

那么，如果用户可以通过单击按钮来发布表单来发出有意的 POST 请求怎么办？允许 javascript 发送 POST 请求是一种灾难，任何加载的恶意页面都可能在幕后执行跨域 POST 请求。

为什么浏览器没有从一开始就阻止这一点？

如果他们这样做了，那么既然 CORS 出现了，POST 请求就可以像 PUT/DELETE 一样被预检，这样您就可以减少 xsrf 攻击了。

【问题讨论】：

标签： http cors csrf same-origin-policy

【解决方案1】：

取消使用 POST 的能力会大大降低 Web 应用程序的功能，而不会显着提高安全性。

如果没有POST，就无法请求另一个域修改数据。（请记住，这是在 CORS 提供选择加入跨域请求的方法之前。）这消除了所有有用的 Web 应用程序。（或者，更有可能的是，Web 应用程序会通过滥用 GET 来解决这个问题。）

而且你不会因为这种牺牲而得到太多回报。任何可能受到跨域 XHR POST 损害的服务器都必须具备 CSRF 保护来处理来自 POST 形式的跨域攻击。而这样的防御（比如要求special token）对两者同样有效。

【讨论】：

"如果没有 POST，就无法请求另一个域修改数据。"您不能对 PUT 和 DELETE 使用相同的逻辑，而是将“修改”替换为“更新”和“删除”吗？我知道您无论如何都可以在帖子中更新和删除，但是，如果您要允许 POST，那么为什么不允许其他两个呢？
@DavidKlempfner：在 Javascript 中不允许使用 PUT 和 DELETE 的原因（以及它们需要使用 CORS 进行预检的原因）是您不能将它们与表单一起使用，并且目标是限制 CSRF 暴露在没有 Javascript 的情况下已经可能发生的事情。至于为什么表单在第一种情况下不允许PUT 和DELETE，我不确定。如果我不得不猜测，我会说没有人认为他们非常需要它们。这是在 REST 之前。根据this history 的说法，并不是每个人都同意它们甚至可以在表单中使用。
为什么将 CSRF 限制在没有 Javascript 的情况下已经可能实现的功能？为什么不更进一步，通过在加载恶意页面时禁止代码运行来使事情更安全，该恶意页面可能会在页面加载后立即在幕后发出 POST 请求？至少对于一个表单，用户必须有目的地点击一个按钮。允许来自带有按钮的表单的 POST 但不允许来自 javascript 的相同 POST 请求是否有任何问题？
@DavidKlempfner：我不确定这与您最初的问题有何不同。这样做的问题在于，它极大地限制了可能的 Web 应用程序的范围，同时几乎没有安全优势。服务器不能假设恶意的第三方页面不会触发表单提交，因此它必须有 CSRF 保护。如果这样做，它还将受到保护，免受恶意第三方脚本的侵害。