必须用-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 就只是在扫一个“假接口”。