1. 先搞明白XSS是怎么溜进来的
跨站脚本攻击就像有人偷偷在你家墙上乱涂乱画，攻击者通过表单提交、URL参数等途径把恶意脚本注入网页。当其他用户浏览这个页面时，这些脚本就会像病毒一样自动执行。常见的攻击场景包括：
- 评论区植入恶意跳转链接
- 用户资料页插入钓鱼表单
- 搜索框参数反射执行脚本
2. 基础防御：配置HTTP响应头（技术栈：Nginx 1.19+）
server {
# XSS防护开关（现代浏览器已弃用但仍有兼容价值）
add_header X-XSS-Protection "1; mode=block";
# 阻止浏览器猜测内容类型
add_header X-Content-Type-Options "nosniff";
# 控制资源加载策略（初级版）
add_header Content-Security-Policy "default-src 'self'";
# 防止点击劫持
add_header X-Frame-Options "SAMEORIGIN";
# 强制HTTPS通信（需配合SSL证书）
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
}
这组配置就像给网站穿上了基础防弹衣，每个头部的具体作用：
X-XSS-Protection：浏览器内置的XSS过滤器开关Content-Security-Policy：限制脚本只能从信任源加载X-Content-Type-Options：阻止MIME类型嗅探攻击X-Frame-Options：防止页面被嵌套在iframe中
3. 进阶防护：定制CSP策略（技术栈：Nginx + CSP 2.0）
# 精细化的内容安全策略
add_header Content-Security-Policy "
default-src 'none';
script-src 'self' 'unsafe-inline' cdn.example.com;
style-src 'self' fonts.googleapis.com;
img-src 'self' data:;
connect-src 'self' api.example.com;
font-src fonts.gstatic.com;
form-action 'self';
frame-ancestors 'none';
report-uri /csp-violation-report;
";
这个配置相当于给网站划定了安全活动区域：
script-src允许的JS来源：本站和指定CDN'unsafe-inline'谨慎开启内联脚本（建议仅在过渡期使用）report-uri收集策略违规报告form-action限制表单只能提交到本站
4. URL参数消毒：过滤特殊字符（技术栈：Nginx + Lua模块）
location /search {
access_by_lua_block {
local args = ngx.req.get_uri_args()
if args.q and string.find(args.q, "[<>'\"&]") then
ngx.exit(ngx.HTTP_BAD_REQUEST)
end
}
proxy_pass http://backend;
}
这段代码像机场安检仪，对搜索参数进行实时检查：
- 使用Lua模块动态检测URL参数
- 当q参数包含<、>等危险字符时直接返回400错误
- 需要安装ngx_http_lua_module模块支持
5. 响应体过滤：动态修改HTML（技术栈：Nginx + Sub_filter）
location / {
sub_filter '</head>' '<meta http-equiv="Content-Security-Policy" content="default-src 'self'"></head>';
sub_filter_once off;
proxy_set_header Accept-Encoding "";
proxy_pass http://backend;
}
这种操作相当于给所有页面自动追加安全防护：
- 在所有页面的尾部插入CSP元标签
- 关闭单次过滤模式确保完全处理
- 需要清除Accept-Encoding防止压缩干扰
6. Cookie安全加固（技术栈：Nginx 1.18+）
proxy_cookie_path / ";/; HttpOnly; Secure; SameSite=Strict";
这条指令让Cookie变成带锁的保险箱：
HttpOnly阻止JavaScript读取Secure仅HTTPS传输SameSite=Strict禁止跨站发送- 分号作为分隔符需要特殊处理
7. 危险文件类型拦截（技术栈：Nginx map指令）
map $uri $blocked_extension {
default 0;
~* \.(exe|msi|bat|sh|php)$ 1;
}
server {
if ($blocked_extension) {
return 403;
}
}
这个配置相当于在服务器门口设置禁入标志：
- 拦截常见可执行文件的上传和访问
- 使用正则表达式匹配文件后缀
- 需要根据业务需求调整黑名单
8. 请求头校验：识别伪造请求（技术栈：Nginx + HttpHeadersMore）
location / {
set $valid_origin 0;
if ($http_origin ~* (example.com|trusted-cdn.net)) {
set $valid_origin 1;
}
more_set_headers -s 403 "X-Block-Reason: Invalid Origin";
if ($valid_origin = 0) {
return 403;
}
}
这种验证就像检查访客的身份证：
- 使用第三方模块增强头处理能力
- 白名单校验请求来源
- 需要安装headers-more-nginx-module
9. 日志监控：捕捉攻击痕迹（技术栈：Nginx + ELK）
log_format security '$remote_addr - $http_user_agent - '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_x_forwarded_for"';
map $status $log_security {
~^[45] 1;
default 0;
}
access_log /var/log/nginx/security.log security if=$log_security;
这个配置相当于安装监控摄像头：
- 单独记录4xx/5xx错误请求
- 使用map指令过滤日志类型
- 需要配合日志分析工具使用
应用场景分析
- 企业官网：适合使用基础CSP策略+响应头组合
- 电商平台：需要强化Cookie安全+动态参数过滤
- 后台管理系统：建议启用严格的内容安全策略
- 开放API服务：重点做好请求来源校验
技术方案优缺点对比
| 方案类型 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 响应头防护 | 配置简单、兼容性好 | 依赖浏览器支持 | 所有Web服务 |
| CSP策略 | 主动防御、灵活可控 | 学习成本较高 | 内容型网站 |
| 动态过滤 | 实时防护、深度防御 | 性能损耗较大 | 高安全要求场景 |
| 日志监控 | 事后追溯、攻击分析 | 无法实时阻断 | 合规审计需求 |
注意事项
- 策略测试：使用CSP Evaluator验证策略有效性
- 渐进实施：CSP策略建议分阶段开启报告模式
- 版本兼容：注意Nginx模块与主版本的兼容性问题
- 性能监控：开启过滤功能后观察QPS变化
- 组合防御：必须配合后端输入验证使用
关联技术延伸
当需要更强大的防护时，可以结合以下方案：
- ModSecurity WAF：专业的Web应用防火墙
location / {
ModSecurityEnabled on;
ModSecurityConfig modsecurity.conf;
}
- 正则表达式强化：精确匹配攻击特征
location / {
if ($query_string ~* "(<script>|eval\(|alert\(|document\.cookie)") {
return 403;
}
}
总结
通过这九种Nginx配置方案，我们构建了从网络层到应用层的立体防御体系。但需要清醒认识到：没有任何单一方案能100%防御XSS攻击。实际部署时要做到：
- 定期使用OWASP ZAP进行渗透测试
- 保持Nginx版本在1.20+以上
- 重要业务开启双因素认证
- 建立持续的安全更新机制
就像给房子安装防盗门的同时还要培养居民的安全意识，技术防御与开发规范相结合，才能打造真正安全的Web应用。