前端安全实战：如何避免 JavaScript 代码中的常见漏洞

• innerHTML / outerHTML
• document.write()
• eval()
• new Function()
• 把字符串当参数传给 setTimeout

这些 API 要么直接执行字符串，要么将其解释为 DOM 结构。而黑客们，最喜欢的就是拿字符串做文章。

请替换成这些安全的替代品：

• textContent
• createElement()
• appendChild()
• 明确的属性设置方法

铁律： 如果浏览器有一丁点可能把你的字符串当成代码去解析，那就直接当成一级红色风险来处理。

'但我明明做了前端校验啊！'

别再自嗨了，纯客户端的验证根本就不是安全防御。

它最多只能算作优化用户体验（UX）的遮羞布。只要是跑在浏览器里的东西，毫无例外，全都可以被轻易绕过。用户可以随手拦截并修改请求。黑客可以疯狂重放 API 调用。随便一个浏览器插件就能把你的业务逻辑改得面目全非。

我见过太多那种前端校验动画做得酷炫无比、严丝合缝的 APP，结果它背后的后端接口却像个不设防的破城门一样大敞着。人家黑客根本连看都懒得看你的前端页面一眼。

建议： 永远、必须在服务器端再做一次绝不妥协的严格校验。没有例外。

原型链污染：90% 前端听都没听过的隐形炸弹

这个概念一旦抛出来，能把一大票老前端都惊出冷汗。

众所周知，JavaScript 对象是继承自原型（prototypes）的。所以，如果黑客有能力篡改 Object.prototype，他们就能瞬间接管并改变你整个应用的底层行为，因为这破应用里几乎所有的东西都在认它当'祖宗'。

常见的背锅侠场景：

• 毫无防备的对象合并（Object merging）
• 网上的深拷贝（Deep copy）工具函数
• 让用户去控制对象的键名（Keys）

举个致命的例子：

function merge(target, source) {
  for (let key in source) {
    target[key] = source[key];
  }
}

这段代码看起来简直无懈可击，对吧？但是，如果那个 source 对象里暗藏着一个叫 __proto__ 的属性，恭喜你，你刚刚亲手把自己的原型链给砸了个稀巴烂。

真正安全的姿势：const obj = Object.create(null); 或者，当键名是动态变化时，老老实实用 Map 吧。

建议： 绝对不要闭着眼睛去合并那些来路不明、不受信任的对象。

第三方脚本：你亲手引狼入室的特洛伊木马

现在哪个 APP 不挂载一堆外部脚本？数据分析、客服弹窗、支付 SDK、UI 辅助库。简直太常见了。理所当然。可是，我亲眼见证过太多次这种惨剧：

• CDN 节点被劫持，分发了被投毒的脚本
• 你信赖的开源依赖包被黑客夺权
• 一次毫无戒心的小版本更新，直接把恶意代码带进了家门

而你的用户，正在被疯狂收割却浑然不知。

建议： 立刻给你的资源加上 SRI（子资源完整性，Subresource Integrity）校验！

<script src="https://cdn.example.com/library.js" 
        integrity="sha384-abc123..." 
        crossorigin="anonymous"></script>

那个看似不起眼的 integrity 属性，会利用哈希算法给你的文件验明正身。如果 CDN 发来的脚本跟预期有一丝一毫的偏差——浏览器就会果断拒绝执行。仅仅加上这么一个属性，你就能彻底干掉一整个维度的安全危机。

绝不能让用户的输入，成为你业务逻辑的方向盘

这种高风险的写法，出现的频率简直高得让人头皮发麻。

const action = req.query.action;
actions[action]();

或者是这种让人窒息的条件判断：if (userRole === "admin") { grantAccess(); }……而这里的 userRole，居然是直接从请求参数里赤裸裸取出来的！

显而易见，当你允许用户的输入去指挥你的代码该跑哪一段时，黑客就已经拿到了你整个系统的最高指挥权。

建议： 必须使用极其严苛的白名单（allow-lists）进行校验。永远不要相信原始的字面量。

细节决定成败

说句掏心窝子的话，我碰到的绝大多数致命漏洞，根本不是什么高深莫测的神仙操作。

它们全部源自于你日常开发中，那些不以为然的微小妥协：

• 图省事用了 innerHTML
• 嫌麻烦跳过了数据转义
• 盲目相信所谓的'内部'数据
• 滥用全局变量
• 对第三方依赖库的审计装聋作哑

压根不需要什么电影里黑客敲键盘的炫酷技巧。仅仅是你应用里最正常的业务行为，就足以让系统万劫不复。

养成这些安全习惯，立刻从'裸奔'变铁壁

如果你想今晚就能睡个安稳觉，马上把精力集中在这几件事上：

✔ 死磕安全的 DOM API ✔ 彻底封杀能执行字符串的函数 ✔ 老老实实做好输出转义 ✔ 果断冻结（Freeze）敏感的核心对象 ✔ 在服务端建立绝不妥协的二次校验 ✔ 定期像查账一样审计你的依赖库 ✔ 拥抱 CSP（内容安全策略）和 SRI

当这些极其苛刻的要求变成你本能反应里的默认习惯时，你代码的安全防线将发生质的飞跃。

到底为什么，悲剧总在重演？

这个问题，我翻来覆去想了很久。

因为整个前端的文化基因，就是被'快'字绑架的。快速迭代功能，快速抢占市场，疯狂推送更新。这种狂热确实催生了无数伟大的产品。但同时也孵化了一个极其病态的环境：安全被轻易抛弃，仅仅因为安全漏洞在爆发前，看起来什么都没有破坏。它们只是像幽灵一样静静地潜伏在那里，耐心地等待。直到有一天，系统轰然倒塌。或者面临更恐怖的结局——核心数据彻底泄露。

结语

写出安全的 JavaScript 代码，不是要求你变成一个被迫害妄想症患者。

它的核心意义在于，你要在那些低级错误进入生产环境之前，直接从物理层面上把整个类别的隐患连根拔起。这并不意味着要把代码写得像天书一样复杂。而是要求你，从一开始就选择一条更安全的默认路径。

因为屏幕那头的黑客，根本不在乎你的 UI 动画有多么丝滑流畅。他们死死盯住的，只有你的浏览器到底会执行什么。而最可怕的是，浏览器这个执行者，只要你敢给，它就敢执行。