From Learn About the Ext JavaScript Library

JSON是一种数据交换格式，可用于机器之间的数据传送。它只是表达数据，所以它本身是与安全无关的。使用JSON的系统安全与否，取决于该系统自身设计的好坏。JSON本身并不会引入安全隐患。

浏览器是一种特别的应用程序环境。在经过长期的预测和跌跌撞撞下，浏览器的安全模型（security model）渐渐地被“锻炼”出来。大多数浏览器的漏洞已经被解决，一些情况下，修补漏洞却又很麻烦，很可能是“拆东墙补西墙”的方式来做的，所以，这种做法，又会导致一系列的错误的出现，继续跌跌撞撞，甚至更痛苦。

良好的习惯做法可避免此类痛苦。通常，所谓的专家，似乎不能够将好的习惯做法和不好的区分开来，使得有好多误导人的建议出现在web上。 下面我分享一下自己几个的“经验之谈”。如果你能抓住这些“经验之谈”，相信你会很快摆脱那些坏习惯。

Contents 1 勿信浏览器（Never Trust Browser） 2 保持数据整洁（Keep Data Clean） 3 Script标签 （Script Tags） 4 切勿发送数据到陌生人（Don’t Send Data To Strangers） 5 使用SSL层加密

勿信浏览器（Never Trust Browser）

浏览器不能够、也不会保护你的秘密，所以切勿发送秘密资料。瑾记服务端是要通过验证的。浏览器验证用户输入只是方便用户，而所有内容发到服务器必须通过验证。

保持数据整洁（Keep Data Clean）

JSON是JavaScript的子集，在WEB程序中很容易使用。由 XMLHttpRequest 得到的文本格式，可通过eval方法快速地转换成为有用的数据结构。但是要注意的是，eval方法非常的不安全。如果服务器生成的JSON有轻轻、小小的错误的话，那换parseJSON解析会更好一些。parseJSON 方法使用正则表达式以保证这段文本没有危险。下一版的JavaScript会有这个方法。现在，你可以在http://www.JSON.org /json.js找到parseJSON。 服务端方面，尽可能使用好的JSON解码、编码器。

Script标签 （Script Tags）

Script可从同源策略（ The Same Origin Policy）中豁免。这意味着从该页面上会潜伏着任何一个站点的脚本。以至会有一些严重的后果。 页面上引用其它站点的脚本是不安全的。外置脚本常用于传送广告、搜索选项、登录、警告、好友列表、或其它有趣的东西。不幸地是，JavaScript 和 DOM的设计中没有预料到这些有用的服务，所以不能提供任何的安全保护。页面上的每段代码都可以访问该页面上的任何一处内容。当你在页面上加载脚本，便允许了脚本能够访问你所有的机密资料，或者是你用户的机密资料。而且也是允许了脚本访问服务器的权限，如用户能够做到的事情一样。究竟怎样区分是用户发起的请求，还是脚本发起的请求，是很难做到的。有朝一日，浏览器会提供某些程度的限制机制。不过那一天没到，script标签一天都是危险的。

Script标签的另外一个用途是“跨域”调用JSON。若果站点发送的是恶意脚本而非JSON数据，这种的情形是绝对没有保障的。所以希望，有朝一日，浏览器会提供安全的跨域数据传输机制。Script标签实在太危险了。

Script标签亦用于传送Ajax库。不要加载其它的库除非你拥有高级别的信任。

切勿发送数据到陌生人（Don’t Send Data To Strangers）

如果你服务器发送敏感的资料到一个恶意的网页，运气好的话会通过。有些情况同源策略会阻止传输，事实却是由于浏览器的BUG缘故数据会通过，浏览器不会受到影响。机密消息的泄露是服务器的责任。这个责任不能推卸到浏览器身上。

所以请求必须认证。Cookies不是适合的认证源，难担机密之重务。类似的对话中，JSON工作的较出色：用JSON的有效负荷中POST一个包含机密的请求，然后得到新机密的JSON响应。

由于Script可从同源策略（ The Same Origin Policy）中豁免，任何页面的Script都是发送GET请求到服务器，请求甚至包含你的COOKIES。所以，如果响应（Reponse）包含机密信息，那你的服务器就应该拒绝该请求。

有些人的做法是在JSON文本外面绕上一些“神奇包裹器（ magic wrappers ）”，就可以防止未认证的用户接收。千万不要信以为真。这会使得新浏览器出现更多BUG,得不偿失。

使用SSL层加密

若然传输、请求机密之消息，请使用SSL。SSL提供了通信线路保密（ link encryption），使得你的消息在传输过程中不被泄露。