Nginx防范XSS的核心是配置安全响应头与请求层拦截。必须添加always参数确保所有响应（含错误页）生效：CSP为现代主力，禁用unsafe-inline/eval；X-XSS-Protection仅作辅助且逐步弃用；配合X-Content-Type-Options和X-Frame-Options构成多层防线。
在 Nginx 环境下防范跨站点脚本攻击（XSS），核心不是靠它“过滤脚本”或“解析 HTML”，而是通过响应头加固、请求层拦截和与后端协同来构建多层防线。Nginx 本身不执行 JS、不渲染页面，所以不能替代应用层的输入校验与输出编码，但能显著抬高攻击门槛。
配置关键安全响应头
所有安全头都应加 always 参数，确保 404、500 等错误响应也携带，避免防护盲区：
-
Content-Security-Policy（CSP）：现代 XSS 防护主力。推荐基础策略：
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self'; form-action 'self';" always;
禁用内联脚本（'unsafe-inline'）、动态执行（'unsafe-eval'）和外部插件（object-src 'none'）可大幅降低利用成功率。 -
X-XSS-Protection：仅作辅助，已逐步被主流浏览器弃用。如需启用，设为：
add_header X-XSS-Protection "1; mode=block" always;
注意：mode=block表示检测到可疑内容直接阻断页面加载，而非尝试修复（后者易被绕过）。 -
X-Content-Type-Options：防止 MIME 嗅探导致浏览器误将文本文件当脚本执行：
add_header X-Content-Type-Options "nosniff" always; -
X-Frame-Options：防御点击劫持（常配合 XSS 扩大危害）：
add_header X-Frame-Options "SAMEORIGIN" always;
若完全不允许嵌入，可用DENY。
在请求入口处做初步过滤
Nginx 可对明显恶意的请求模式做快速拦截，不转发给后端，减轻压力：
- 屏蔽含典型 XSS 载荷的查询字符串：
if ($query_string ~* "(|%3C|%3E|script|javascript|alert|eval|onerror|onload)") { return 403; } - 限制 User-Agent 中的危险字符（部分扫描器/自动化工具会注入）：
if ($http_user_agent ~* "(|%3C|%3E|script|eval)") { return 403; } - 禁止非法路径穿越或双斜杠绕过：
if ($request_uri ~ "\.\./|\.\.$|//") { return 400; }
⚠️ 注意：if 在 location 外使用有风险，建议仅用于简单匹配；复杂逻辑应交由 WAF（如 ModSecurity）或后端处理。
适配多租户等特殊场景
若业务涉及多租户，需确保安全头策略不被租户间干扰：
- 按域名识别租户时，用
map提取并校验租户 ID，非法值直接return 400，不进入代理流程。 - 每个租户的 CSP 策略应独立配置（如不同 CDN 域名、不同
script-src白名单），避免“一策通吃”引发兼容问题。 - 禁用
X-XSS-Protection更稳妥——尤其当租户前端使用 React/Vue 等框架，其内联事件绑定易被浏览器默认过滤器误杀。
配套建议与验证方式
光配头不够，还需闭环验证和持续优化：
- 用
curl -I https://yoursite.com检查响应头是否生效，重点确认是否含 CSP、nosniff和SAMEORIGIN。 - CSP 初期建议先用
Content-Security-Policy-Report-Only收集违规日志，再逐步收紧策略，避免误伤正常功能。 - 所有防护都不能替代后端的输入过滤（白名单校验）、输出编码（HTML/JS/CSS 上下文分别转义）和可信数据源管理。
- 定期更新 Nginx 版本，关注 CVE 公告；生产环境建议搭配轻量级 WAF（如 Naxsi）增强规则维度。
