防止原型链污染的核心是严格验证外部输入，尤其在对象合并、属性设置和反序列化时；2. 应使用白名单机制过滤属性名，禁止\_\_proto\_\_、constructor等敏感键；3. 使用仅复制自有属性的深拷贝函数或structuredclone等安全api，避免lodash.merge等易受攻击的库；4. 可通过object.freeze(object.prototype)冻结原型以阻止修改，但需评估对旧代码的影响；5. 在键名来自用户输入时，优先使用map而非普通对象，因其不依赖原型链查找，可天然免疫污染；6. 攻击原理是通过可控路径如\_\_proto\_\_.admin向object.prototype注入属性，影响所有继承对象；7. 常见风险操作包括深层合并、路径式赋值及不安全的反序列化逻辑；8. 检测手段包括代码审计、依赖扫描（如npm audit）、运行时proxy监控和编写模拟攻击的测试用例，确保防御有效。完整防御需结合输入控制、安全api、架构设计与持续检测。
防止JavaScript原型链污染，核心在于严格控制和验证所有外部输入，特别是在进行对象合并、属性设置或反序列化操作时。这不仅仅是技术细节，更是一种安全意识的体现。
解决方案
在我看来，防范原型链污染，没有银弹，但可以构建一个多层防御体系。
首先，最关键的是输入验证和清理。任何来自用户或外部系统的数据，在被用来构造对象路径或作为属性名之前，都必须经过严格的白名单验证。这意味着你不能信任任何包含__proto__、constructor等敏感关键字的键名，或者任何可能被解析为路径的字符串。我个人偏好使用白名单机制，明确定义允许的属性和结构，而不是试图黑名单所有可能的恶意输入，因为黑名单总有漏网之鱼。
其次，是安全地处理对象合并和深拷贝。许多流行的库，如lodash.merge、jQuery.extend(true, ...)等，在处理递归合并时，如果源对象包含可控的__proto__或constructor.prototype路径，就可能被利用。所以，当你需要深拷贝或合并对象时，如果源数据来自不可信来源，务必使用那些明确设计为抵抗原型链污染的函数。比如，你可以自己实现一个只复制“自有属性”（own properties）的深拷贝函数，或者使用像structuredClone（如果环境支持）这样更安全的API。或者，如果你必须使用这些库，确保在合并前对输入数据进行彻底的清理，移除所有可能触发污染的键。
再者，可以考虑冻结关键原型。在应用启动阶段，你可以通过Object.freeze(Object.prototype)来冻结Object.prototype。这样一来，即使攻击者试图向其添加或修改属性，操作也会失败。这是一种非常激进但有效的防御手段，不过需要注意的是，它可能会对某些依赖于运行时修改Object.prototype的旧代码或库产生副作用，所以需要谨慎评估。
最后，使用Map代替普通对象存储数据，尤其是在处理键名可能来自用户输入的情况时。Map的键可以是任何值，并且它不会触发原型链查找，因此天然免疫于原型链污染。这是一种非常优雅且直接的解决方案，在某些场景下可以大幅简化安全考量。
理解JavaScript原型链污染的攻击原理
原型链污染，说白了，就是攻击者通过某种方式，向JavaScript对象的原型链上注入或修改属性，从而影响到所有继承自该原型的对象。这听起来有点抽象，但想象一下，Object.prototype是所有普通JavaScript对象的“祖宗”。如果我能在你家的“祖宗牌位”上刻上点什么，那么你家所有后代（所有普通对象）就都会带着这个“印记”。
具体来说，攻击通常利用了JavaScript在查找对象属性时的机制。当你访问obj.property时，如果obj本身没有这个property，JavaScript就会沿着obj.__proto__（即其构造函数的prototype）向上查找，直到找到或者到达null。如果攻击者能控制某个输入，使得这个输入在被处理时，能够构造出__proto__或constructor.prototype这样的路径，并给它赋值，那么这个赋值就会落在Object.prototype上。
例如，一个常见的攻击模式是obj[__proto__][key] = value。如果你的代码中有一个函数，它接受用户输入来设置一个深层属性，比如set(obj, path, value)，而path是用户可控的，那么攻击者就可以传入path = "__proto__.admin"，value = true。这样，Object.prototype.admin就被设置为true了。之后，任何新建的对象，或者没有admin属性的对象，在尝试访问obj.admin时，都会查到Object.prototype上的admin，从而可能绕过权限检查或触发其他意想不到的行为。更恶劣的，攻击者可能覆盖一些关键的内置方法，导致拒绝服务，甚至在某些环境下结合其他漏洞实现远程代码执行。
在实际项目中，哪些常见的操作或库可能导致原型链污染？
在日常开发中，原型链污染往往不是直接被“写”出来的，而是间接通过一些看似无害的操作或库的特定用法引入的。我见过最常见的“罪魁祸首”是那些深层合并（deep merge）或对象扩展（object extend）的工具函数。
比如，你可能经常用到lodash的_.merge()或者jQuery.extend(true, ...)。这些函数的设计目的是将多个对象的属性递归地合并到目标对象上。如果其中一个源对象是用户可控的，并且它包含了类似{ "__proto__": { "isAdmin": true } }这样的结构，那么在合并过程中，isAdmin这个属性就可能被注入到Object.prototype上。很多时候，开发者在处理配置对象、用户偏好设置或者API响应数据时，会不假思索地使用这些深层合并工具，而没有意识到潜在的风险。
另一个常见的场景是基于路径的属性设置函数。有些库或自定义工具函数允许你通过一个字符串路径来设置对象的属性，例如set(obj, 'user.profile.name', 'Alice')。如果这个path字符串是用户可控的，攻击者就可以传入__proto__.someProperty来污染原型。类似的，一些ORM/ODM库或者数据绑定框架，如果它们在处理用户提交的数据时不够谨慎，也可能存在这种风险。
此外，不安全的JSON反序列化也可能成为入口。虽然标准的JSON.parse()本身不会触发原型链污染，因为它只解析数据，不执行代码。但如果你的应用在解析JSON后，紧接着进行了一些自定义的对象构建或属性赋值逻辑，并且这个逻辑没有对键名进行严格校验，那么攻击者就可能通过构造恶意的JSON数据来利用这个后续的逻辑。例如，如果一个自定义的反序列化器会递归地将JSON对象的键值对映射到目标对象上，并且没有过滤__proto__，那问题就来了。
除了防御，如何检测并响应潜在的原型链污染攻击？
除了主动防御，建立一套检测和响应机制同样重要，毕竟安全是道持续的攻防战。
首先，代码审计和安全审查是基础。定期对项目代码进行人工审查，特别关注所有处理外部输入、进行对象合并、深拷贝或动态属性设置的地方。寻找__proto__、constructor.prototype等敏感字符串的出现，以及这些字符串是否可能被外部输入控制。这需要一定的安全经验，但却是发现潜在漏洞最直接的方式。
其次，可以利用依赖项安全扫描工具。现代的包管理器（如npm）都提供了安全审计功能（npm audit），可以检测你项目中使用的第三方库是否存在已知的安全漏洞，包括原型链污染漏洞。Snyk等专业的安全工具也能提供更深入的扫描和报告。保持依赖库的最新版本，是堵住已知漏洞的有效手段。
再者，考虑运行时监控和异常检测。虽然这在前端实现起来比较复杂，但在Node.js后端，你可以尝试监控Object.prototype的修改。例如，通过在开发或测试环境中，对Object.prototype设置一个Proxy，一旦有非预期的属性被添加或修改，就立即发出警报。当然，这在生产环境可能会有性能开销，需要权衡。
最后，编写针对性的安全测试用例。在单元测试或集成测试中，专门加入原型链污染的攻击场景。例如，构造包含__proto__键的恶意输入，然后尝试传入你的深拷贝函数、API接口等，验证它们是否能正确地拒绝或处理这些输入，而不是污染原型。这是一种“以攻代守”的策略，确保你的防御措施确实有效。如果测试失败，说明你的防御存在漏洞，需要立即修复。
