proxy本身不是漏洞，但使用不严谨会放大风险；关键在于规范使用场景、严格校验输入、禁止代理敏感对象和危险操作，并通过冻结+proxy双重防护、调用栈分析、单层职责聚焦等措施构建纵深防御。
Proxy 本身不是漏洞，但用得不严谨，反而会放大风险。关键不在“用不用”，而在“怎么用、用在哪、有没有兜底”。
别把 Proxy 当万能胶，尤其别代理敏感对象
开发者常把 Proxy 套在全局配置、用户凭证、权限状态等对象上，美其名曰“监控”或“增强”。一旦 handler 中的 get/set 没做输入校验，或直接透传未经清洗的数据，就等于给攻击者开了个调试后门。
- 避免代理包含 token、密钥、session ID 的对象；如必须代理，应在 set 拦截中拒绝写入非法值（比如非字符串、含 script 标签的值）
- 不要用 Proxy 包裹 window、document 或第三方 SDK 实例——它们内部可能依赖原生行为，代理后易引发兼容性问题或绕过安全检查
- 对代理目标做浅层冻结（Object.freeze）+ Proxy 双重防护，防止原型篡改或属性动态注入
拦截逻辑里禁用危险操作，不放行 eval 类行为
Proxy 的 apply 和 construct 拦截可控制函数调用与实例化，但若 handler 内部仍调用 eval、setTimeout(字符串)、new Function 等，等于把风险从明处藏到暗处。
- 在 apply 拦截中检查 argumentsList，若发现参数含 user-input 字符串且疑似脚本（如含 <script>、<a style="color:#f60; text-decoration:underline;" title= "javascript"href="https://m.php.cn/zt/15724.html" target="_blank">javascript:、onerror=），直接 throw 或静默丢弃</script>
- 禁止在 handler 中拼接并执行动态代码；需运行远程逻辑时，走白名单接口 + 后端鉴权，而非前端解析执行
- 对 construct 拦截做类型约束：只允许已知构造器（如 new Date()、new Map()），拒绝 new Function()、new XMLHttpRequest() 等高危类
日志与监控不能只记“调用了”，要判“该不该调”
很多团队用 Proxy 做调试代理，但只记录“谁访问了哪个属性”，却不判断访问上下文是否合法。攻击者正利用这种“有日志无判断”的盲区试探接口边界。
- 在 get/set 中加入调用栈分析：若调用源自不可信源（如内联 script、eval 上下文、第三方 iframe），则标记为可疑并限流
- 对高频访问同一敏感属性（如 userInfo.token）的行为触发告警，而非仅记录
- 配合 CSP 报告机制，将 Proxy 拦截到的异常访问同步上报，形成前后端联动审计线索
代理链要短，避免嵌套多层 Proxy 带来不可控副作用
有些架构为“增强安全性”，层层套 Proxy：数据层 → 校验层 → 日志层 → 权限层。结果是性能下降、错误堆栈混乱，更严重的是，某一层的拦截疏漏会被下一层掩盖，反而掩盖真实风险点。
- 单个对象最多一层 Proxy，职责聚焦（要么只做校验，要么只做审计，不混用）
- 不同安全目标用不同机制隔离：权限控制用策略模式，日志用独立中间件，数据校验用 Zod/Yup 等专用库，别全塞进 Proxy handler
- 上线前用静态分析工具扫描 Proxy 使用点，识别出未设 fallback、无 error 处理、或 handler 过于宽泛的代码段
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
