JavaScript有效防止原型污染影响属性存在性检查

# 防止原型污染：属性存在性检查的正确姿势 谈及 Ja vaScript 原型链污染，许多开发者的第一反应往往是“如何检查才安全”。然而实际上，这个问题真正值得深入探讨的，并非“检查”这个动作本身，而是“使用哪个对象进行检查”以及“采用何种方式检查”。简而言之，核心思路只有一个：**绕过原型链，避免依赖对象自身的方法，从源头切断污染入口**。 ## 推荐方案：Object.hasOwn() 才是真正的“银弹” ES2022 引入的 `Object.hasOwn(obj, 'key')` 可以说是专门为解决此类问题而设计的。为什么它值得信赖？因为它直接检测对象的自有属性，完全绕过原型链，也不调用 `obj` 上的任何方法。即使遇到 `Object.create(null)` 创建的无原型对象，或者 `hasOwnProperty` 被重写为字符串，它依然能返回正确结果。 对比就能清晰看出差异： - 使用 `'key' in obj` 的问题在于，它会沿着原型链逐级向上查找。一旦 `Object.prototype.key = true` 被污染，即使是空对象，也会返回 `true`。 - 使用 `obj.hasOwnProperty('key')` 看似不错，但该方法本身可能被覆盖或删除。一旦被篡改，调用就会报错，或返回错误结果。 好消息是，现代环境（Node.js 16.9+、Chrome 93+ 等）已原生支持 `Object.hasOwn`。如果必须兼容旧环境，使用 polyfill 降级处理即可。 ## 老环境兼容：固定调用原始 hasOwnProperty 如果项目仍需支持 IE 或早期 Node.js，则不能直接写 `obj.hasOwnProperty('key')`。正确的做法是显式绑定到原始实现上：**`Object.prototype.hasOwnProperty.call(obj, 'key')`**。 为何要这样写？因为它直接跳过 `obj` 自身的属性查找路径，始终使用未被污染的原生逻辑。即使 `obj` 是空对象、`null` 原型对象，或者它的 `hasOwnProperty` 属性被赋值为 `undefined`，这个调用也不会崩溃。 ## 别踩的坑：用值判断冒充存在性检查 `obj.key !== undefined` 或 `if (obj.key)` 这种写法，看似简单，实则是在进行值判断，而非存在性检查。它既不安全，也不准确。 - 属性存在但值恰好为 `undefined`，会误判为“不存在” - 属性是 getter 且内部抛出错误（例如访问 `null.name`），程序直接中断 - 更关键的是，它无法区分“未定义”和“定义了但值为 falsy”（如 `0`、`false`、`''`） ## 治本之道：从源头切断污染路径 再安全的检查方法，也防不住已被污染的原型。真正可靠的防御思路，是在输入端将所有“危险钥匙”收走： - 所有外部输入（JSON body、URL 参数、表单数据）解析后，立即递归扫描，将 `__proto__`、`constructor`、`prototype` 等键名全部移除。注意，不能只查顶层，必须递归到底。 - 创建纯数据容器时，优先使用 `Object.create(null)`——没有原型链，天然免疫。 - 深拷贝和合并操作应避开 `_.merge` 等高危函数。Node.js 环境可启用 `--disable-proto=throw` 以彻底禁止 `__proto__` 的写入。 - 服务启动时，若确认没有合法库依赖，可冻结 `Object.prototype`：`Object.freeze(Object.prototype)`。这样任何试图修改原型的行为都会静默失败或报错。 当然，最理想的状态是“不让污染发生”。从输入到输出，每一步都做好防御，属性存在性检查只是最后一道防线。