反向代理不直接防御原型链污染，但可通过四策阻断：过滤__proto__等敏感键、重置可信转发头、隔离管理接口、净化响应敏感信息。
反向代理本身不直接防御原型链污染（Prototype Pollution）这类 JavaScript 运行时漏洞，因为该漏洞发生在后端应用层（如 Node.js 服务解析 JSON、合并对象时未校验键名），而非网络代理层。但巧用反向代理的核心安全模块，可构建强隔离边界，切断攻击者利用原型链污染向内网负载均衡组件渗透的路径——关键在于“阻断污染输入抵达目标”和“限制污染后果扩散”。
以下四点是切实可行、已在生产环境验证的防护策略：
严格过滤并重写可疑请求头与参数
原型链污染常通过 ?__proto__[admin]=true 或 {"__proto__":{}} 等形式注入，攻击者试图污染全局对象以覆盖配置、绕过鉴权或触发 SSRF。反向代理应在入口层主动拦截：
- 使用
mod_rewrite（Apache）或map+if（Nginx）拒绝含__proto__、constructor、prototype字样的查询参数或请求体（需配合client_body_buffer_size限制体大小） - 清除客户端伪造的
X-Forwarded-*头（如X-Forwarded-Host: ${__proto__.evil}），防止污染被透传至后端 - 对 JSON 类型请求（
Content-Type: application/json），启用mod_security规则或 Nginx 的lua-resty-waf检查顶层键名合法性，直接400 Bad Request
强制标准化转发头，切断污染传递链
后端负载均衡逻辑若依赖 X-Forwarded-For 或 X-Forwarded-Proto 做路由决策，而这些头被污染，可能导向错误节点。必须由反向代理“重置可信上下文”：
- Apache：
RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}s"（仅设真实客户端 IP） - Nginx：
proxy_set_header X-Forwarded-For $remote_addr;（禁用$proxy_add_x_forwarded_for） - 同时移除所有用户可控头：
proxy_hide_header X-Forwarded-Host; proxy_hide_header X-Forwarded-Scheme;
隔离管理接口与数据平面，物理阻断横向移动
内网负载均衡器（如 HAProxy 管理页、Nginx balancer-manager、Consul UI）若暴露在代理后且未鉴权，原型链污染可能被用于构造 XSS+CSRF 组合拳劫持控制台。必须：
- 将管理端口（如
:8080/admin）从反向代理配置中彻底剥离，仅允许内网运维 IP 直连 - 若必须代理，添加强认证（如
auth_basic+ LDAP/AD）+ IP 白名单 +Require expr %{REQUEST_URI} =~ m#^/api/v1/balance/# - 禁用所有非必要 HTTP 方法（
DELETE/PUT/TRACE）对管理路径
启用请求体深度校验与响应头净化
攻击者可能通过污染触发后端异常响应，泄露内网拓扑（如 X-Upstream: 10.1.2.3:8080）。代理层应：
- 对返回状态码为
5xx的响应，自动移除X-Powered-By、Server、X-Upstream等敏感头 - 使用
mod_headers（Apache）或sub_filter（Nginx）扫描响应体，匹配并替换10\.\d+\.\d+\.\d+、192\.168\.\d+\.\d+等内网地址为[REDACTED] - 开启
SSLStrictSNIVHostCheck on（Apache）或ssl_verify_client off配合证书双向认证（如需），防止中间人篡改请求流
不复杂但容易忽略
