原型链本身不是安全边界，而是安全漏洞的放大器，因其委托机制导致污染会自动蔓延至所有继承该原型的对象；防御应聚焦输入解析层过滤敏感键、对象创建层使用object.create(null)、工具函数层选用structuredclone或冻结object.prototype等关键断点。
JavaScript 原型链本身不是安全边界，而是安全漏洞的放大器——它的委托机制一旦被污染，影响范围会自动蔓延到所有继承该原型的对象。
原型链为何构成安全敏感路径
原型链的查找机制决定了属性访问具有“隐式传播性”：当代码读取 obj.x 时，引擎自动沿 obj → obj.__proto__ → obj.__proto__.__proto__ → … → Object.prototype 向上查找。这意味着：
- 任何可被用户控制输入写入原型（如通过 lodash.merge、JSON.parse + 深拷贝）的位置，都可能成为污染入口；
- 污染一旦到达 Object.prototype，所有普通对象（包括请求体解析结果、配置对象、DOM 元素等）都会意外获得该属性；
- __proto__、constructor.prototype、prototype 这三类键名是常见攻击向量，尤其在反序列化或配置合并场景中极易触发。
真实存在的安全边界位置
安全控制点不在原型链“中间”，而集中在几个关键断点：
-
输入解析层：对 JSON、URL 查询参数、表单数据做白名单字段过滤，禁止
__proto__、constructor、prototype等敏感键名进入对象字面量； - 对象创建层：用 Object.create(null) 创建无原型基础对象（如路由表、配置缓存），彻底切断委托链；
-
工具函数层：避免使用存在原型污染风险的库方法（如
_.merge、$.extend），改用structuredClone或手动遍历赋值； -
运行时防护层：在服务启动时冻结 Object.prototype（
Object.freeze(Object.prototype)），虽不能阻止已有污染，但可阻断后续注入。
为什么不能靠“修复原型链”来防御
试图在运行时动态重置原型或拦截 __proto__ 赋值，既不可靠也不推荐：
- Object.setPrototypeOf() 和直接写 __proto__ 会破坏 V8 内联缓存，导致性能陡降；
- 修改已有对象的原型无法撤回已发生的属性查找行为（例如某个中间件已读过污染属性并缓存了结果）；
- 框架（如 Express、Vue）内部大量依赖 instanceof 和原型方法，擅自改动易引发兼容性断裂。
更务实的安全实践方向
把原型链当作不可信通道，转而构建显式、可控的数据流：
- 用 Proxy 封装用户输入对象，拦截对敏感键的设置操作并抛出错误；
- 将配置/上下文对象设计为不可扩展（
Object.preventExtensions()）且密封（Object.seal()），限制结构变更； - 在 Node.js 中启用 --no-deprecation 并监控
process.on('warning')，及时捕获原型相关弃用警告； - 前端侧避免将服务端返回的任意 JSON 直接用作对象原型（如
Object.setPrototypeOf(data, MyProto)），改用组合方式注入行为。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
