Object.freeze 保护前端配置文件的实战方法

本文深入剖析了前端配置文件防护中 Object.freeze 的实际局限与正确用法：它仅能浅层冻结，嵌套对象和数组内部依然可被篡改；真正可靠的保护必须通过严格时机执行的递归 deepFreeze 实现，并在模块加载最前端完成，否则其他模块已缓存未冻结引用将导致整个防护失效；同时强调冻结前必须切断原型链、杜绝代理与访问器注入，否则攻击者仍可通过原型污染、构造函数扩展或 Proxy 绕过。核心结论直击要害——配置安全不取决于冻结逻辑多精巧，而在于“是否在任何模块读取前就已完成彻底冻结”。

Object.freeze 本身做不到“彻底保护”，它只冻结第一层属性；嵌套对象、数组内部仍可被随意修改，攻击者只要拿到引用就能绕过。

为什么 config.api.timeout 被锁住，但 config.api.baseUrl 还能改

因为 Object.freeze 是浅冻结：它只让 config 自身的属性（如 api、debug）不可写、不可配置，但 config.api 这个对象本身没被 freeze，它的属性依然可读可写。

• 常见误操作：const config = JSON.parse(fs.readFileSync('./config.json')); 后直接 Object.freeze(config)
• 实际效果：config.debug = false 失败（顶层被锁），但 config.api.headers.token = 'hacked' 成功（子对象完全开放）
• 数组同理：config.features[0].enabled = false 会成功，哪怕 config.features 是个冻结数组

真正起作用的 deepFreeze 必须递归且时机严格

必须自己实现递归冻结，并在模块加载链最前端执行——晚一秒，其他模块可能已缓存了未冻结的引用。

• 用这个函数（兼容循环引用和已冻结检查）：

  function deepFreeze(obj) {
    if (obj === null || typeof obj !== 'object') return obj;
    if (Object.isFrozen(obj)) return obj;
    Object.getOwnPropertyNames(obj).forEach(prop => {
      if (obj[prop] !== null && typeof obj[prop] === 'object') {
        deepFreeze(obj[prop]);
      }
    });
    return Object.freeze(obj);
  }

• 调用位置必须是入口文件最顶部（Node.js）或 ESM 模块的顶层作用域（浏览器），例如：import config from './config.js'; deepFreeze(config); export { config };
• 禁止在导出语句里直接 freeze：export default Object.freeze({...}) —— 打包器可能提前解析，导致嵌套对象逃逸

冻结后仍可能被绕过的三个隐蔽路径

即使 deepFreeze 完成，以下操作仍可能破坏一致性：

• Object.setPrototypeOf(config, null) 不行 —— 冻结后无法改原型，但若冻结前没切断继承，config.__proto__.evil = 1 会污染原型链；建议冻结前加 Object.setPrototypeOf(config, null)
• config.constructor.prototype.hijack = ... —— 如果 config 是某个自定义类实例，其 constructor 原型未冻结，就存在扩展风险；纯配置应只用 plain object / array
• Reflect.defineProperty(config, 'fake', { value: 1 }) —— 冻结后该调用静默失败，但若攻击者控制了 config 的 getter/setter 注入点（比如通过 Proxy 包装后再 freeze），freeze 就失效；所以冻结前不能有任何代理或访问器注入

最关键的不是代码写得多漂亮，而是冻结动作是否发生在**所有模块拿到 config 引用之前**——漏掉这一步，后面全白干。

到这里，我们也就讲完了《Object.freeze 保护前端配置文件的实战方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！