有许多针对 JSON 的安全攻击，尤其是 XSRF。

当 Web 服务使用 cookie 进行身份验证，并使用包含敏感数据的 JSON 数组响应 GET 请求时，就会出现该漏洞。

如果攻击者可以欺骗登录服务 naive-webapp.com 的用户访问他们的网站（或任何嵌入他们控制的 IFRAME 的网站，例如通过嵌入广告），那么他们可以插入<script>带有 SRC的标签以naive-webapp.com，并可能窃取用户的数据。这取决于 JavaScriptArray构造函数的 javascript 怪癖，如下所示：

 <script>
   // Overload the Array constructor so we can intercept data
   var stolenArrays = [];
   var RealArray = Array;
   Array = function () {
     var arr = RealArray.apply(arguments);
     stolenArrays.push(arr);
     return arr;
   }
 </script>
 <!-- even though the attacker can't access the cookies,
   - he can cause the browser to send them to naive-webapp.com -->
 <script src="//naive-webapp.com/..."></script>
 <script>
   // now stolenArrays contains any data from the parsed JSON
 </script>

EcmaScript 5 修复了导致[]查找Array全局对象的混乱行为，许多现代浏览器不再容易受到这种攻击。

顺便说一句，Oil 关于不可预测的 URL 是错误的。URL 中加密安全的随机标识符是保护资源的好方法。正如石油所暗示的那样，基于身份的安全性并不是万能药。请参阅http://waterken.sourceforge.net/以获取基于 URL 中加密安全标识符的安全分布式应用程序方案的示例，该方案不需要身份概念。

编辑：

在考虑 JSON 与 XML 时，您还应该了解特定于 XML 的攻击向量。

XXE，XML 外部实体攻击，使用精心制作的 XML 来通过防火墙访问文件系统和网络资源。

<!DOCTYPE root 
[
<!ENTITY foo SYSTEM "file:///c:/winnt/win.ini">
]>
...
<in>&foo;</in>

应用程序将输入（参数“in”，包含 win.ini 文件）嵌入到 Web 服务响应中。

博客 (CSRF) 中的主要安全漏洞不是特定于 JSON 的。使用 XML 也是一个大漏洞。事实上，根本没有异步调用也同样糟糕；常规链接同样容易受到攻击。

当人们谈论唯一 URL 时，他们通常不是指http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement。相反，更常见的是使请求的其他内容变得独特；即 FORM 帖子中的一个值，或一个 URL 参数。

通常这涉及在服务器端插入到 FORM 中的随机令牌，然后在发出请求时进行检查。

数组/对象对我来说是新闻：

脚本标签：攻击者可以嵌入一个指向远程服务器的脚本标签，浏览器会为你有效地 eval() 回复，但是它会丢弃响应，因为 JSON 是所有响应，所以你是安全的。

在这种情况下，您的站点根本不需要使用 JSON 就容易受到攻击。但是，是的，如果攻击者可以将随机 HTML 插入您的站点，那么您就干杯了。

它仍然是最好的与不可预测的网址，以保护您的数据安全。

强调我的。胡说些什么！这是最好的与最重要的是一些正确的身份验证，可能还有一些加密来保护您的数据安全。JSON 交换仍然可以使用现有的身份验证技术（例如通过 cookie 的会话）和 SSL。

当您使用 JSON 将数据导出到匿名第三方（例如 Web 服务）时，依赖于没有猜测 URL（他们实际上在谈论什么）的人只会是一种合理的技术（即使如此，也只是） . 一个例子是谷歌的各种网络服务 API，匿名用户通过其他网站访问谷歌数据。他们使用域引用和 API 密钥来确保中间人网站被允许提供 Gooogle 数据。

如果您只是使用 JSON 与直接的、已知的用户代理来回发送私有数据，请使用一些真正的身份验证和加密。如果您正在尝试提供网络服务，那么这实际上取决于这些数据的“安全”程度。如果它只是公共数据并且您不介意谁可以阅读它，那么我认为制作散列 URL 没有意义。

编辑：为了演示它们的含义，请考虑这一点。想象一下，您的银行提供了一个用于获取报表的 JSON API。如果我可以只输入http://yourbank.com/json-api/your-name/statement，你可能不会很高兴。

他们可以为您的帐户生成任何 JSON 请求中所需的唯一字符串，例如： http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement

我猜到这一点的机会要小得多。但您真的希望它成为您真正安全的数据和潜在身份窃贼之间的唯一缓冲吗？不。