A field-tested sqlmap reference: target specification, request shaping, detection tuning, DBMS fingerprinting, enumeration, dumping, file system access, OS command execution, evasion, and tamper scripts. Grouped by what you are actually trying to do.
sqlmap is an open-source command-line tool that automates the detection and exploitation of SQL injection, from fingerprinting the database to dumping data, reading files, and dropping an OS shell. This cheat sheet groups the flags I actually reach for by task: target specification, request shaping, detection tuning, DBMS fingerprinting, enumeration, dumping, file system access, OS command execution, evasion, and tamper scripts.
--flush-sessionDiscard cached state for this target. Start fresh.
--fresh-queriesRe-run cached query results.
-oTurn on all optimisations (--keep-alive, --null-connection, --threads=3).
--output-dir=./outWhere to save the session, log, and dumps. Default ~/.local/share/sqlmap.
--dump-format=CSVOutput format: CSV, HTML, or SQLITE.
Evasion and tamper
--tamper=between,randomcase,space2commentApply tamper scripts to obfuscate payloads. Chainable comma-separated list.
--skip-wafSkip the heuristic WAF detection step. Faster on known-WAF targets.
--identify-wafRun only the WAF identification step. Tells you which product is in front.
--hppHTTP parameter pollution. Splits payload across duplicate parameters.
--chunkedSend POST body via Transfer-Encoding: chunked. Some WAFs do not reassemble correctly.
--null-connectionUse HEAD requests for true/false detection. Faster, sometimes evades content-based WAFs.
sqlmap ships with hundreds of flags. I use maybe forty of them regularly. This is the field reference for the ones that matter, grouped by the task I am trying to accomplish, with a short note on when each one is worth reaching for.
req.txt is a raw HTTP request file: method line, headers, blank line, body. Most of my commands use -r req.txt because it carries the entire request shape (method, headers, cookies, body) without re-typing. Here is what it actually looks like:
code
GET /product?id=1 HTTP/1.1
Host: target.example
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9
Accept-Language: en-US,en;q=0.9
Cookie: session=eyJhbGciOiJIUzI1NiJ9...; PHPSESSID=q9k2...
Connection: close
POST requests look the same with the method and body added:
code
POST /login HTTP/1.1
Host: target.example
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
Cookie: PHPSESSID=q9k2...
Connection: close
username=admin&password=test
No special markers, no per-parameter annotations. sqlmap tests every parameter it finds in the request unless you restrict with -p. Mark a specific injection point with * only if you want to force sqlmap there.
You do not need Burp Suite for this. The DevTools built into Chrome and Firefox can produce everything sqlmap needs. Two paths, easiest first:
Easiest: save a HAR and skip writing req.txt by hand.
Open DevTools: F12 on Windows/Linux, Cmd+Option+I on macOS.
Open the Network tab. Enable Preserve log so a navigation does not wipe the captured requests.
Trigger the target request in the page (click the link, submit the form, hit the API).
Right-click any captured request in the list. In Chrome pick Save all as HAR with content. In Firefox pick Save All As HAR. Save as traffic.har.
Point sqlmap at the HAR directly with --har instead of -r:
bash
sqlmap --har=traffic.har --batch
sqlmap lists every request it found in the HAR and asks which one to test. Pick the one carrying the parameter you want to probe. From then on the workflow is identical to the req.txt examples below, just swap -r req.txt for --har=traffic.har.
If you prefer an actual req.txt (worth the extra step when you want to hand-edit headers or insert a * injection-point marker):
Same DevTools / Network tab setup.
Click the request you want to capture. In Chrome open the Headers tab inside that request's panel; in Firefox the Headers tab is the default.
Copy the request method line and every request header into a text file. The browsers display them in the right order already.
Add a blank line, then the request body (if any). For POST forms that is the URL-encoded body. For JSON APIs it is the raw JSON.
Save as req.txt. Use with -r req.txt in every example below.
If you want a shortcut for the manual path: right-click the request → Copy → Copy as cURL (both browsers support this). The cURL command contains the URL, every header, and the body. You can either run that through a converter (curlconverter --language http <command> from npm, or any online cURL-to-HTTP tool) or just read it and assemble req.txt by hand: cURL's -H "Foo: bar" flags become header lines verbatim, --data 'x=y' becomes the body, and the URL gives you the method line.
A few command lines I use as starting points and adapt from. The first batch uses the captured request file from the section above. The simpler ones below take a -u URL directly when you just need a quick probe.
Edit the values once and every example updates. The User-Agent dropdown defaults to --random-agent because the literal sqlmap default UA is signatured by every commercial WAF.
Try it with your own values
Tune the common flags once. Every command below reads from this. Out-of-range values get a red border. The Googlebot UA usually gets you hard-blocked faster than the default; pick it only when you know the target trusts crawlers.
Simplest possible probe, just a URL with a query string. Good for a first sanity check before you bother capturing a request:
Every flag above is dual use. The same --dump that exfiltrates a production user table is the one I run against my own lab targets fifty times a week. Use these against systems you own or are explicitly authorised to test. See the authorisation block at the top of this page and the legal-framing notes in the SQL injection deep dive.
Level controls how many injection points and how many payload variants are tested. Risk controls how dangerous the payloads themselves are. Level 5 with risk 1 tests cookies, headers, and user-agent with safe payloads. Level 1 with risk 3 tests only the obvious parameters but uses payloads that may write or update data. Default is level 1 risk 1, which is intentionally cautious.
Most common causes: default level/risk are too low for the location (header injections need level 3+), the parameter is detected as anti-CSRF or session and skipped (use -p to force it), the response differential is below sqlmap's detection threshold (set --string or --not-string explicitly), or the payload boundary is unusual (use --prefix and --suffix to match).
Yes, with --batch for non-interactive mode and --output-dir for predictable artefacts. The harder problem is making the target deterministic: spin up a known-vulnerable target (or your real staging app), run a fixed set of requests through Burp/your own proxy, save them as request files, and have sqlmap consume those. Avoid --crawl in CI; it makes the run nondeterministic.
By every commercial WAF, yes. The default contains the string 'sqlmap' which is on every signature feed in the industry. Always set --random-agent or a hand-crafted --user-agent for any real engagement. Open-source/self-hosted WAFs vary.
Sources
Authoritative references this article was fact-checked against.
Software Systems Architect · Senior Software Engineer · Engineering Leadership
Software systems architect and senior software engineer with more than two decades designing, building, and running production software, Linux systems, and DevOps infrastructure, and lately working AI into the stack. Now a CTO, though what I write here is drawn from the full arc of that work, across architecture, engineering, and operations, not any single job.
A field-tested LFImap reference: target selection, traversal wordlists, PHP wrappers (filter/input/data/expect/file), command injection, RFI, log/proxy/cookie shaping, second-order requests, and the `PWN` placeholder. Grounded in the real argparse surface.
A field-tested fuxploider reference: target shaping, true/false response detection, extension fuzzing, cookies and headers, proxying, threading, and what to do once a webshell uploads. Grounded in the real argparse surface.