核心是配置csp为主力、x-xss-protection为辅助、x-content-type-options和x-frame-options为配套的多层防护，所有头必须加always参数确保错误响应不漏防。
在 Nginx 的 server 块中配置安全响应头防御 XSS，核心是启用多层防护机制：以 Content-Security-Policy（CSP）为主力，辅以 X-XSS-Protection（仅作过渡兼容），并必须搭配 X-Content-Type-Options 和 X-Frame-Options 形成纵深防御。所有头都需加 always 参数，确保 404、500 等错误响应也不漏防。
必须配置的 CSP 策略（现代 XSS 防御核心）
CSP 是目前最有效、浏览器原生支持的 XSS 防御手段，它通过白名单机制严格控制脚本能从哪里加载、是否允许内联或动态执行：
- 禁用高危指令：明确拒绝
'unsafe-inline'（禁止内联 script/style）、'unsafe-eval'（禁止 eval/Function 构造器） - 限定脚本来源：只允许同源（
'self'）和可信 CDN（如https://cdn.example.com） - 阻断插件与对象：设
object-src 'none'防止 Flash/Java 插件执行恶意代码 - 限制表单提交目标：用
form-action 'self'防止钓鱼表单劫持
示例配置（放在 server 块内）：
可选但建议保留的 X-XSS-Protection（兼容旧浏览器）
该头已被 Chrome/Firefox 逐步弃用，但在部分旧版 IE/Edge 中仍有作用。若启用，务必使用阻断模式：
- 用
"1; mode=block"：检测到可疑脚本注入时直接停止页面渲染，不尝试修复（避免被绕过） - 必须加
always：否则 304 或 500 响应不带此头，形成防护缺口 - 不推荐仅设
"1"或"0"：前者可能降级为“修复模式”，后者等于主动放弃防护
配置示例：
add_header X-XSS-Protection "1; mode=block" always;配套基础安全头（缺一不可）
这些头虽不直接防 XSS，但堵住常见绕过路径，是 CSP 能生效的前提：
-
X-Content-Type-Options: nosniff —— 防止浏览器 MIME 嗅探，避免将
text/plain文件误解析为可执行脚本 - X-Frame-Options: SAMEORIGIN —— 防点击劫持，避免攻击者用 iframe 嵌套你的页面后诱导用户触发 XSS payload
- 若需兼容百度统计等第三方工具，可用
ALLOW-FROM https://tongji.baidu.com替代SAMEORIGIN
配置示例：
add_header X-Content-Type-Options "nosniff" always;add_header X-Frame-Options "SAMEORIGIN" always;
请求层简单过滤（增强入口防护）
不能替代应用层过滤，但可在 Nginx 层快速拦截明显恶意请求，减轻后端压力：
- 屏蔽含典型 XSS 载荷的查询字符串：
if ($query_string ~* "(%3C|%3E|script|javascript|alert|onerror|eval)") { return 403; } - 拦截危险 User-Agent（如扫描器）：
if ($http_user_agent ~* "(curl|python-requests|sqlmap|nikto)") { return 403; } - 注意：
if应放在server块顶层，且确认 Nginx 版本支持（1.19+ 更稳定）
