ModSecurity本身不自带SQL注入规则，必须显式启用OWASP CRS并正确配置：需加载modsecurity.so、include crs-setup.conf和REQUEST-942等规则文件、设置SecRuleEngine On，且确保请求体解析（SecRequestBodyAccess On）和异常评分链完整，否则规则无法生效。
ModSecurity 本身不自带 SQL 注入规则，必须显式启用 OWASP Core Rule Set（CRS）并正确配置，否则 SecRule 不会拦截任何 SQLi 请求。
确认 ModSecurity 已加载且 CRS 规则已启用
很多部署失败源于模块加载了但规则没生效。先验证 modsecurity.so 在 Nginx 配置中被 load_module 加载，再检查是否在 http 或 server 块中启用了 CRS 的主规则文件：
- 路径常见为
/usr/local/owasp-crs/crs-setup.conf和/usr/local/owasp-crs/rules/REQUEST-912-DOS-PROTECTION.conf等，需用include显式引入 - 必须包含
SecRuleEngine On，仅SecRuleEngine DetectionOnly不会阻断请求 - CRS v3.3+ 要求先加载
crs-setup.conf，否则规则变量（如tx.allowed_methods）未定义，导致大量误报或规则失效
SQL 注入检测依赖 REQUEST-942 规则集，但默认行为可能放行
OWASP CRS 将 SQLi 检测集中在 REQUEST-942-APPLICATION-ATTACK-SQLI.conf，但它不是独立开关——实际触发受多个条件制约：
- 请求需匹配
SecAction中定义的phase:1初始化动作，否则后续规则不初始化上下文 - 若后端应用使用
Content-Type: application/json且未启用SecRequestBodyAccess On，JSON body 中的id=1' OR '1'='1类型 payload 将完全跳过解析和检测 - CRS 默认对
GET参数检测严格，但对POST表单字段（application/x-www-form-urlencoded）也有效；若用multipart/form-data上传表单，需确保SecRequestBodyLimit足够大且SecRequestBodyNoFilesLimit合理，否则解析中断导致规则失效
绕过常见、必须堵住的配置缺口
攻击者常利用配置疏漏绕过检测，以下三点不处理，SecRule 形同虚设：
-
SecResponseBodyAccess Off是默认值，不影响 SQLi 检测，但若开启并设错SecResponseBodyMimeType（如漏加text/html），会导致响应体规则误判，不过这不是 SQLi 拦截的关键点 - 未设置
SecResponseBodyLimit 524288以上，当后端返回长 HTML（含错误堆栈）时，ModSecurity 截断响应体，使RESPONSE-953-DATA-LEAKAGES.conf类规则失效——虽不直接影响 SQLi 阻断，但会掩盖注入成功后的数据泄露迹象 - 最危险的是
SecRuleRemoveById误删规则：例如为兼容某个老接口而禁用942100（基于正则的 UNION SELECT 检测），等于主动打开一个高危通道；应优先用SecRuleUpdateTargetById缩小作用域，而非全局移除
真正起效的 SQLi 防御不是靠单条 SecRule，而是 CRS 整个规则链的协同：从参数解析、编码规范化（REQUEST-920-PROTOCOL-ENFORCEMENT.conf）、到多阶段模式匹配（REQUEST-942）和异常评分累积（REQUEST-949-BLOCKING-EVALUATION.conf）。漏掉任意一环，比如忘记 SecResponseBodyAccess On 却又依赖响应体做二次判断，防御就出现可预测的裂缝。
