我看到过关于这个主题的文章和帖子（包括SO），主要的评论是同源策略阻止跨域表单POST。我唯一看到有人建议同源政策不适用于表单帖子的地方就是这里。
我想从一个更"官方"或正式的来源得到答案。例如，有人知道RFC吗，它解决了相同来源如何影响或不影响表单POST的问题？
澄清：我不是在问是否可以构建GET或POST并将其发送到任何域。我在问：
- 如果Chrome、IE或Firefox允许域"Y"中的内容向域"X"发送POST
- 如果接收POST的服务器将实际看到任何表单值。我这么说是因为大多数在线讨论记录测试人员说服务器收到了帖子，但表单值都是空的/去掉了
- 什么样的官方文档（即RFC）解释了预期的行为（无论浏览器当前实现了什么）
顺便说一句，若相同的来源不会影响表单POST，那个么它就更清楚地说明了为什么防伪代币是必要的。我说"有点"是因为很容易相信攻击者可以简单地发出HTTP GET来检索包含防伪令牌的表单，然后进行包含相同令牌的非法POST。评论？
同源策略仅适用于浏览器端编程语言。因此，如果你试图使用JavaScript发布到不同于原始服务器的服务器，那么相同的原始策略就会发挥作用，但如果你直接从表单发布，即操作指向不同的服务器，如：
<form action="http://someotherserver.com">
如果在发布表单时没有涉及javascript，那么同源策略就不适用。
有关更多信息，请参阅维基百科
可以构建任意的GET或POST请求，并将其发送到受害者浏览器可访问的任何服务器。这包括本地网络上的设备，如打印机和路由器。
有很多方法可以构建CSRF漏洞。可以使用.submit()方法发送简单的基于POST的CSRF攻击。更复杂的攻击，如跨站点文件上传CSRF攻击，将利用CORS使用xhr.withCredentals行为。
CSRF不违反JavaScript同源策略，因为SOP涉及JavaScript读取服务器对客户端请求的响应。CSRF攻击不关心响应，而是关心副作用，或请求产生的状态更改，例如添加管理用户或在服务器上执行任意代码。
确保您的请求使用OWASP CSRF预防作弊表中描述的方法之一得到保护。有关CSRF的更多信息，请参阅CSRF上的OWASP页面。
同源策略与将请求发送到另一个url（不同的协议、域或端口）无关。
这一切都是关于限制访问（读取）来自另一个url的响应数据。因此，页面中的JavaScript代码可以发布到任意域，也可以将该页面中的表单提交到任何地方（除非表单位于具有不同url的iframe中）。
但是，使这些POST请求效率低下的是，这些请求缺乏防伪造令牌，因此被其他url忽略。此外，如果JavaScript试图通过向受害者url发送AJAX请求来获取安全令牌，则同源策略会阻止其访问该数据。
一个很好的例子：这里是
Mozilla提供了一个很好的文档：这里是