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