我知道JSON.parse（）可以防止攻击者将javascript注入到响应中，因为JSON解析器只是一个文本解析器，而不是脚本解析器所以请不要关闭这个是关于所有其他问题的重复。这是一个不同的问题。
如果攻击者可以劫持你的Ajax调用并将javascript放入Ajax调用，那么他们是否有可能劫持你的实际网页并将任意javascript放入你可以完成同样攻击的页面？
当然，通过使用JSON.parse（）而不是eval（），你没有什么可失去的（除非你的环境中还没有JSON解析器，并且必须添加更多代码才能获得），但它确实是什么情况呢？如果您的网页由与ajax呼叫相同的主机提供服务，请增加安全性吗？
是的，这真的更安全。 您不采取的每项预防措施都是一组您无法阻止的潜在攻击。
攻击者可能无法控制服务器的输出而无法完全更改它。没有人认为它是一个神奇的子弹，但它可能更快，你不会创造一个潜在的漏洞，可能会回来并伤害你。
也许运行你的服务器的人有一个糟糕的一天，并做一些愚蠢的事情，如通过连接未经过验证的用户输入构建JSON：
<?php
print '{"foo": ' . $_GET['bar'] . '}';
?>
如果你正在使用 JSON.parse他们能做的最糟糕的事情就是把一个大物体塞进你的记忆中。如果你正在使用 eval 他们可以劫持一切。
好吧，如果他们能够注入你的AJAX响应，他们可能已经成功地以某种方式让你中间（ARP，DNS或其他）。
看到 http://en.wikipedia.org/wiki/Man-in-the-middle_attack 有关这些类型的攻击的更多详细信息。
你是正确的，如果他们可以注入你的AJAX响应，他们也可以注入整个页面。实际上，除非使用HTTPS \ SSL之类的东西，否则您收到的任何内容或通过网络发送的内容现在都会在MitM中受到攻击。
这是一个非常好的观点。我唯一能想到的就是那个 JSON.parse 会有更快的机会 eval。
如果浏览器已经缓存了HTML / JavaScript且服务器使用了，则不太可能的优势 Cache-Control 说它不需要重新加载。如果发生这种情况，那么当然拦截的人将没有机会修改页面。但这是一种非常罕见的情况。有可能，您将需要浏览器检查HTML / JavaScript的较新版本，这是默认行为。
至于安全性差异，我认为你是对的。
至于我自己，我只使用HTTPS确认的系统。但我有一个使用的功能 JSON.parse 如果可以的话又会重新开始 eval 只是为了提高速度。
嗯......我不是在提倡使用 eval，但我认为这不构成安全问题 在Javascript中，因为Javascript是客户端语言。如果你不使用 eval 在你的代码中，是什么阻止我运行 javascript:my_own_evil_code() 在控制台或地址栏？它是Javascript，我可以运行自己的代码或修改你的代码，创建我自己的HTTP请求，并做任何HTTP响应，甚至添加我自己的 eval 你的功能。
你不应该使用 eval 如果有另一种类似的解决方案可用，但如果你只是为了简单，就想做 eval('('+jsonstring+')') 模仿 JSON.parse，我不认为这是一个大错误。