HTTP请求头注入与XSS防御需坚持“不信任任何客户端输入”，严控User-Agent等头字段直接输出，须对所有反射头字段白名单过滤或结构化清理，禁止Unicode控制字符、HTML实体及javascript:伪协议。
HTTP 请求头注入与 XSS 漏洞的防御不能靠单一手段，核心在于“不信任任何客户端输入”，尤其要严控从请求头（如 User-Agent、Referer、X-Forwarded-For、Origin）中读取并直接输出到页面的内容。
严格校验和净化请求头字段
很多 XSS 漏洞源于将未处理的请求头值（例如通过 request.getHeader("User-Agent")）直接写入 HTML 或 JavaScript 上下文。必须对所有可能被前端反射使用的头字段做白名单过滤或结构化清理：
- 只允许 ASCII 字母、数字、常见分隔符（如空格、斜杠、括号），拒绝 Unicode 控制字符、HTML 实体编码、JavaScript 伪协议（
javascript:、）等；
- 对需输出到 HTML 的头值，使用上下文感知的编码：插入到 HTML 文本用
HtmlEncoder.encode()，插入到属性值用属性编码，插入到 JavaScript 字符串则用 JSON 字符串转义（如 <code>JSON.stringify()）； - 禁用动态拼接头值进内联脚本或事件处理器（如
onerror="doSomething('{{UA}}')"），改用 DOM API 安全赋值或数据属性 + 后续 JS 处理。
禁止头字段参与反射型输出逻辑
反射型 XSS 最常发生在错误页、登录跳转页、统计埋点页中——这些页面常把 Referer 或 Origin 直接回显。应主动规避此类设计：
- 错误提示页统一使用静态文案，避免回显原始头信息；
- 重定向跳转逻辑中，若需保留来源标识，应仅记录日志或存入服务端 session，而非在响应中反射
Referer； - 确需显示来源信息时（如调试模式），先比对可信域名白名单，再做 HTML 编码后输出，且限制长度（如截断至 64 字符）。
启用安全响应头构筑纵深防线
即使代码存在疏漏，合理配置响应头可大幅降低 XSS 利用成功率：
-
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'—— 建议移除'unsafe-inline'和'unsafe-eval'，改用nonce或hash策略管控内联脚本； -
X-Content-Type-Options: nosniff防止 MIME 类型混淆导致浏览器误解析； -
X-XSS-Protection: 0（现代应用建议关闭旧式过滤器，依赖 CSP）； -
Strict-Transport-Security和Referrer-Policy: strict-origin-when-cross-origin辅助降低中间人与泄露风险。
服务端日志与监控增强检测能力
攻击者常通过构造恶意头试探过滤逻辑，例如发送含 <script>alert(1)</script> 的 User-Agent。应在网关或应用层记录异常头内容，并触发告警：
- 对包含
、<code>>、、<code>'、javascript:、onerror=等特征的请求头，记录 IP、时间、头名、截断值； - 结合 WAF 规则（如 ModSecurity 的
SecRule REQUEST_HEADERS "@rx (?:）实现前置拦截； - 定期审计日志中高频出现的非常规 UA/Referer，识别自动化扫描行为。
