这个问题有点重复：为什么XMLHttpRequest的原始策略相同
但是，此答案并不令人满意，因为它没有解决存在变通方法的事实（如问题中所述）。答案仅解决了与XMLHttpRequest直接相关的安全性问题，但是JSONP仍然存在这些问题（可能不确定CORS）。因此，问题仍然存在- 当存在诸如JSONP之类的变通方法甚至更糟（因为它是可执行文件而不是静态内容）时，为什么要制定严格的Same Origin策略？
这是一个示例：Company.com希望对一些不受保护的资源进行AJAX调用，例如用于一些数据查找的简单公共API。Company.com意识到这可能是不安全的，因此他们将仔细清理数据以确保没有可笑的事情。但是，XMLHttpRequest不允许这样做，因此Company.com必须使用JSONP，但这将防止数据清理，并可能导致攻击者向页面注入任意Javascript。这是一个更好的解决方案吗？
另一个例子：Company.com存在漏洞，攻击者能够将Javascript注入页面，然后某些用户可以查看该页面（可能有百万种发生方式；这可能是最常见的网站攻击）。使用严格的“同源来源”策略，攻击者可以整天弄乱页面，但他不能“回拨”，这是一个重要的细节，因为这意味着您的所有数据都是安全的。但是JSONP（和图像标签）通过允许攻击者从页面抓取您的所有个人数据并将其发送到任何地方而打破了这一点。即使使用CORS，这仍然是现实，因为我可以告诉流氓服务器允许来自任何域的入站XS请求。
换句话说，在哪种情况下，锁定的XMLHttpRequest实际上可以提供更高的安全性吗？
您的前提不正确。同源策略没有说明网页在外部域中包含资源的能力。这样可以防止通过不同来源的脚本直接访问资源，而无需选择它们。
因此，CORS和JSONP并非Same Origin策略的解决方法。CORS使Origin可以选择加入具有响应的XHR请求，而JSONP只是一种黑客，它允许外部引用将动态数据返回到页面。
这里的重点是保护您的页面，这样一来就不可能使用XSS。为此，重点应放在正确编码输出到页面的文本上。这将防止“打电话回家”，因为首先不可能进行攻击。一个内容安全策略可以帮助中和管理通过网滑倒任何脚本。您网站上的定期安全漏洞评估应获取未编码的输出- 将CSP视为在找到和修复它们之间的空白，尽管浏览器还不完全支持（尤其是Internet Explorer）。
但是，XMLHttpRequest不允许这样做，因此Company.com必须使用JSONP，但这将防止数据清理，并可能导致攻击者向页面注入任意Javascript。这是一个更好的解决方案吗？
它不是。CORS是更好的解决方案，因为请求将检索数据而不是可执行代码。CORS允许XMLHttpRequest做到这一点。
使用CORS响应标头Access-Control-Allow-Origin，网站所有者example.com可以将其设置为
Access-Control-Allow-Origin
example.com
Access-Control-Allow-Origin: https://company.com
以仅允许company.com客户端通过用户浏览器通过HTTPS访问数据。
company.com
在这种CORS方案中，example.com仅信任company.com该特定请求的数据响应。与Access-Control-Allow- Credentials标头结合使用时，他们可以选择在其浏览器处向用户请求用户的任何授权Cookie，并将其与请求一起发送，并在处由JavaScript读取响应company.com。
Access-Control-Allow- Credentials
在JSONP情况下，company.com将信任example.com与 他们的整个原产地 。这意味着他们信任example.com整个客户端站点安全模型。Example.com可以对company.com网站进行任何操作。因此，如果example.com受到黑客的威胁，company.com一旦每个用户访问包含<script src="https//example.com/…标签的页面，他们也可以控制用户会话。
Example.com
<script src="https//example.com/
互联网上无处不在。
假设您已登录Gmail。出于争议考虑，假设Gmail具有一种AJAX方法，该方法可以获取您的收件箱内容：
https://gmail.com/services/inbox/get_conversations
现在，您正在浏览网页，并进入了我的网站evil.com。
evil.com
Evil.com包含一些向发出POST请求的JavaScript https://gmail.com/services/inbox/get_conversations，它将在您登录时将cookie从发送gmail.com回gmail.com。
Evil.com
gmail.com
处的服务https://gmail.com/services/inbox/get_conversations将忠实地返回收件箱中的内容。
如果没有使用“相同来源策略” evil.com将其锁定，则将能够读取此响应中的数据。即任何站点都可以阅读您的电子邮件。使用“相同来源策略”时，数据将返回到浏览器，但没有客户端脚本可以读取数据gmail.com（当然还有CORS允许的任何其他来源）。例如，在这种情况下，Google可能允许以下内容：
Access-Control-Allow-Origin: https://google.com
注意：以上所有内容均由我作为示例进行说明，绝不反映Google和Gmail的实际操作方式。原则上是一样的。
