第一个防御是通过使用需要一个对象作为顶级实体的有效 JSON来坚持规范。所有已知的攻击都基于这样一个事实：如果顶级对象是一个数组，则响应是可以使用 <script> 标记解析的有效 Java Script 代码。

如果 JSON 响应包含任何机密/非公开数据，则仅在请求经过身份验证时才提供响应（例如，带有指示经过身份验证的会话的 cookie）。

这是攻击的先决条件，而不是缓解措施。如果浏览器有站点 A 的 cookie，它将包含在对站点 A 的所有请求中。即使请求是由站点 B 上的 <script> 标记触发的，也是如此。

如果 JSON 数据包含任何机密或非公开内容，请将其托管在不可猜测的秘密 URL 上（例如，包含 128 位加密质量随机数的 URL），并且仅与授权查看的用户/客户端共享此秘密 URL数据。

URL 不被视为一种安全功能。所有常见的搜索引擎都有浏览器插件/工具栏，可以将任何访问过的 URL 报告给搜索引擎供应商。虽然他们可能只报告明确访问的 URL，但我也不会为 JSON URL 冒险。

让客户端以 POST（而不是 GET）的形式发送对 JSON 数据的请求，并让服务器忽略对 JSON 数据的 GET 请求。

这将阻止 <script> 包含。

把 while(1); 在 JSON 响应的开头，并让客户端在解析 JSON 之前将其剥离。

我建议对这种方法进行修改：在开头添加</*. while(1)存在问题的原因有两个：首先，它可能会触发恶意软件扫描程序（在客户端、代理和搜索引擎上）。其次，它可用于针对网络冲浪者 CPU 的 DoS 攻击。这些攻击显然来自您的服务器。

Google 使用“无法解析的垃圾”来防御这种类型的攻击。此漏洞已在 firefox 3 中修复。该漏洞源于浏览器如何实现 JSON 规范。

1) 如果 JSON 响应包含任何机密/非公开数据，则仅在请求经过身份验证时才提供响应（例如，带有指示经过身份验证的会话的 cookie）。2) 如果 JSON 数据包含任何机密或非公开内容，请将其托管在不可猜测的秘密 URL（例如，包含 128 位加密质量随机数的 URL），并且仅与授权的用户/客户端共享此秘密 URL看数据。

没有充分的理由同时执行 (1) 和 (2)。

第一个是ABAC，第二个是ZBAC。试图通过使用多种访问控制方案进行纵深防御只是过于复杂的事情。

3) 放在while(1);JSON 响应的开头，并让客户端在解析 JSON 之前将其剥离。

4) 让客户端将 JSON 数据的请求作为 POST（而不是 GET）发送，并让服务器忽略对 JSON 数据的 GET 请求。

这些听起来像是好主意，并且确实增加了深度防御，因为它有助于确保凭据不会被盗用。

此外，

5) 仅通过 SSL 或其他一些安全通道提供带有敏感数据的 JSON。

防止通过 MITM 泄露数据。