Nginx 本身不内置 SQL 注入、XSS 或命令注入等应用层防护模块，但可通过 ModSecurity+OWASP CRS、原生指令过滤及分层协同防护实现生产级注入防御。
在 Nginx 中，**Nginx 本身不内置 SQL 注入、XSS 或命令注入等应用层防护模块**，它不是 WAF（Web 应用防火墙），但可以通过以下几种成熟、轻量且生产可用的方式为 Nginx 添加注入类安全防护能力。
使用 ModSecurity + Nginx（推荐）
ModSecurity 是最主流的开源 Web 应用防火墙引擎，支持 Nginx（需编译集成或使用动态模块）。它能识别并拦截常见的注入攻击模式（如 SQLi、XSS、路径遍历、远程代码执行等）。
- 安装方式：推荐使用 ModSecurity v3 + nginx connector（modsecurity-nginx），避免老旧的 v2 + ngx_http_modsecurity_module（已停止维护）
- 规则集：默认搭配 OWASP Core Rule Set（CRS），开箱即可防御典型注入行为（如
union select、script>、eval($_POST等） - 配置示例（nginx.conf 片段）：
load_module modules/ngx_http_modsecurity_module.so; server { modsecurity on; modsecurity_rules_file /etc/nginx/modsec/main.conf; ... } - 注意：需确保 Nginx 编译时启用
--with-compat，并正确加载动态模块；CRS 规则建议启用 SecRuleEngine On（检测+拦截）或 DetectionOnly（仅记录）
利用 Nginx 原生指令做基础过滤
对轻量场景或临时加固，可借助 if + return 或 map 拦截明显恶意特征，但不能替代 WAF，仅作辅助。
- 禁止常见 SQL 关键字出现在 URI 或参数中（简单粗暴，慎用于含合法关键词的业务）：
if ($args ~ "(union\s+select|select\s+\*|insert\s+into|drop\s+table|script>|javascript:|eval\()") { return 403; } - 更稳妥做法：用
map提前匹配并设变量，再在 location 中判断，避免 if 在 location 外滥用 - 限制请求体大小（防大 payload 注入）：
client_max_body_size 1m; - 禁用危险 HTTP 方法：
if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE|OPTIONS|PATCH)$ ) { return 405; }
结合后端应用与网关层协同防护
Nginx 是入口，但真正理解业务语义的是应用。安全防护必须分层：
- 在 Nginx 层做“第一道过滤”（如封禁扫描器 IP、限速、阻断已知攻击指纹）
- 在应用层做参数校验、预编译查询（防 SQLi）、输出编码（防 XSS）、白名单输入（如只允许数字 ID）
- 若使用云 WAF（如 Cloudflare、阿里云 WAF）或 Kubernetes Ingress Controller（如 NGINX Ingress + WAF 插件），可将 ModSecurity 部署在更前置位置，减轻 Nginx 自身压力
其他实用增强项
提升整体抗注入能力的配套措施：
-
开启安全响应头：防止 XSS 和 MIME 类型混淆
add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "DENY" always; add_header X-XSS-Protection "1; mode=block" always;
-
隐藏 Nginx 版本号：减少被针对性攻击风险 —— 设置
server_tokens off; -
日志记录可疑请求：在 log_format 中加入 $args、$request_body（需开启
log_subrequest on），便于溯源分析 - 定期更新规则与组件：OWASP CRS、ModSecurity、Nginx 本体均需保持更新，尤其关注 CVE 修复
不复杂但容易忽略：防护效果高度依赖规则质量与调优。上线前务必在测试环境用 SQLMap、XSStrike 等工具验证拦截效果，并根据误报调整 CRS 的 paranoia level 或自定义规则。
