必须用-r参数或--data/--headers/--cookie显式传入完整请求上下文，否则sqlmap -u会漏掉post、json、鉴权等关键注入点；--level=3和--risk=3为上线前检测最低要求。
直接跑 sqlmap -u 很可能漏掉关键注入点
上线前接口检测不是“随便找个带参数的URL跑一下”就行。很多核心接口走 POST、带 JSON body、依赖 Cookie 或 Header（比如 X-Auth-Token），默认只传 -u 会完全跳过这些请求体里的参数。
必须用 --data、--headers、--cookie 或 -r（从文件读原始 HTTP 请求）显式带入完整上下文：
- POST 表单接口：用
--data="username=admin&password=123"，别指望-u自动解析 body - JSON 接口：
--data='{"id":1}' --headers="Content-Type: application/json"，否则 sqlmap 当成普通 GET 处理 - 带鉴权的接口：必须加
--cookie="sessionid=abc123"或--headers="Authorization: Bearer xxx"，否则返回 401 就停了 - 最稳妥方式是抓包导出
.txt（Burp 的 “Copy as curl” 或 “Save item” → “Request in file”），再用-r request.txt
--level 和 --risk 不调高，根本测不出深层盲注
默认 --level=1 --risk=1 只测 URL 参数和基础 payload，对布尔盲注、时间盲注这类无回显场景几乎无效——而生产接口恰恰大量使用这类逻辑判断。
上线前检测必须至少设为：
-
--level=3：强制测试 Cookie、User-Agent、Referer、X-Forwarded-For 等所有 HTTP 头字段 -
--risk=3：启用堆叠查询、AND (SELECT ...)等高风险 payload，否则绕不过 WAF 的基础规则 - 如果目标用了 PostgreSQL 或 Oracle，额外加
--dbms=postgresql或--dbms=oracle，避免 sqlmap 花时间猜错数据库类型导致误判
批量检测多个接口时，-m 文件格式稍有不慎就全失败
-m urls.txt 看似简单，但实际容易卡在三类问题上：
- 文件里每行必须是完整可执行的请求，不能只有路径（如
/api/user?id=1），得带协议和域名（https://api.example.com/api/user?id=1） - 含空格或特殊字符（如
&、=）的 URL 必须用引号包裹，否则 shell 解析错位；更稳妥的是统一用-r+ 单独的请求文件 - 不同接口鉴权方式不一致时，
-m无法为每行指定独立 Cookie 或 Token，此时必须拆成多个命令，或改用--scope配合正则过滤
建议上线前先挑 3–5 个高频核心接口（登录、订单提交、用户资料更新）单独跑，确认能稳定识别注入后再批量。
WAF 存在时，--random-agent 和 --delay 基本没用，得换 tamper
现在很多业务前置了云 WAF（如阿里云、腾讯云、Cloudflare），--random-agent 这种基础混淆根本过不去。真正有效的做法是选对 --tamper 脚本：
- 阿里云 WAF：优先试
--tamper=space2comment,apostrophenullencode，把空格转成/**/、单引号转成%bf%27 - Cloudflare：用
--tamper=charencode,randomcase，编码关键字符并随机大小写 - 自研 WAF：先手工验证几个 payload 是否被拦截（如
id=1 AND SLEEP(5)），再反向查 sqlmap 的tamper/目录里哪个脚本能绕过对应特征 - 注意：
--delay=0.5对时间盲注有效，但对报错注入或 UNION 注入反而拖慢检测速度，上线前时间紧时建议只在确认是盲注后才加
真正难啃的点往往不在工具本身，而在你是否清楚这个接口背后的真实请求链路——Header 怎么传、Token 怎么续期、Body 是 form 还是 JSON、WAF 规则到底拦了什么。漏掉其中一环，sqlmap 就只是在扫一个“假接口”。
