nginx 中防 xss 应优先配置 csp 并辅以 x-xss-protection(设为 "1; mode=block" 且加 always),禁用仅限严格后端防护+已配 csp 场景;还需配合 x-content-type-options、x-frame-options 等安全头并均加 always。

在 Nginx 中配置防止 XSS 的响应头,核心是正确设置 X-XSS-Protection,但需注意它只是辅助手段,不能替代应用层防护。现代实践中更推荐配合 Content-Security-Policy(CSP)使用。
启用浏览器内置 XSS 过滤器
添加以下指令可激活并强化浏览器的 XSS 过滤行为:
add_header X-XSS-Protection "1; mode=block" always;-
必须加
always:否则错误响应(如 404、500)不会携带该头,留下防护缺口 -
mode=block表示检测到可疑脚本时直接阻止页面加载,而非尝试修复(后者可能被绕过)
禁用 XSS 过滤器的适用场景
某些前端框架或富文本场景下,浏览器默认过滤可能误拦截合法脚本。此时可显式关闭:
add_header X-XSS-Protection "0";- 仅在后端已做严格输入校验、输出编码、且部署了 CSP 的前提下才考虑此配置
- 禁用后若服务端防护不足,XSS 风险会显著上升
用 CSP 替代或增强 XSS 防护
X-XSS-Protection 已被 Chrome、Firefox 等主流浏览器逐步弃用。更可靠的做法是配置 Content-Security-Policy:
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self';";- 禁止内联脚本(
'unsafe-inline')、动态执行('unsafe-eval'),能大幅降低 XSS 利用成功率 - 建议先用
Content-Security-Policy-Report-Only头收集违规报告,再逐步收紧策略
配套安全头不可少
XSS 防护效果依赖多层协同,以下响应头应一并配置:
-
add_header X-Content-Type-Options "nosniff" always;:防止浏览器 MIME 嗅探导致脚本误执行 -
add_header X-Frame-Options "SAMEORIGIN" always;:避免点击劫持间接放大 XSS 危害 - 所有安全头都建议加上
always,确保错误响应也受保护











