sqlmap
--batch, --technique=BEU (safe). Part of AuditCore's automated security audit pipeline — runs on every scan in the Enterprise tier and above, with findings normalized into a single severity-rated table.
What is sqlmap?
sqlmap is the de-facto open-source tool for automating SQL injection detection and exploitation. AuditCore runs it as the deepest layer of our injection-phase scanning — after the lighter ZAP active scan flags candidate parameters, sqlmap goes in with payload sets that cover boolean-blind, error-based and union-based techniques across MySQL, PostgreSQL, MSSQL, Oracle, SQLite and 30+ other DBMS variants.
We run sqlmap with `--batch --technique=BEU --risk=2 --level=3 --smart`. The `BEU` technique restriction is deliberate: it covers Boolean, Error and Union-based detection, but excludes Stacked queries and Time-based blind, both of which can DoS shared databases or trigger destructive secondary queries. `--smart` skips parameters that don't show heuristic SQLi indicators, keeping run time bounded. `--threads=4 --timeout=15` keeps it polite without sacrificing depth.
Findings are normalized into AuditCore's vulnerability model: each confirmed injection becomes one finding with severity Critical (or High for blind/limited), the affected URL + parameter, the DBMS fingerprint, and a remediation hint that links to our `/fix/sql-injection` guide. If you're using parameterized queries everywhere and sqlmap still flags something, it's almost always a dynamic ORDER BY clause or LIKE pattern that wasn't allow-listed — both covered in the fix guide.
sqlmap is included in the Enterprise tier because it actually exploits the vulnerability to confirm it (no false positives) and because exploitation tooling needs explicit authorization. If you want SQLi detection without exploitation, the Pro tier's ZAP active scan covers it heuristically.
What it tests
- Boolean-based blind SQL injection (`AND 1=1` / `AND 1=2` differential)
- Error-based SQL injection (DBMS error message extraction)
- Union-based SQL injection (column-count enumeration + data extraction)
- DBMS fingerprinting across 35+ database engines
- WAF/IPS detection and tamper-script bypass (we use `space2comment` by default)
- Form-based injection via `--forms --crawl=2`
- GET/POST parameter coverage from the recording proxy + ZAP-discovered URLs
- Cookie injection, custom HTTP header injection
- Database schema enumeration (proof-of-impact)
- Out-of-band detection via DNS exfiltration (where the target permits)
Where it runs in the AuditCore pipeline
Phase 4/5 · Injection & Active Tests
Active payload-based scanning — SQL, NoSQL, command, template, XXE, SSRF, prototype pollution, race conditions, AI prompt injection, business-logic abuse, plus full ZAP / Nuclei / sqlmap.
Source: scanners/sqlmap_scanner.py
Sample findings
SQL injection in /search?q=… via boolean-based blind
Critical severity. Confirmed by 200ms response-time differential between `' AND 1=1-- -` and `' AND 1=2-- -` payloads. DBMS fingerprint: PostgreSQL 14.2. Mitigation: switch to parameterized queries (the fix-guide template covers Node/Python/PHP/Go/Ruby/Java).
Error-based SQLi in /api/products?category=…
Critical. DBMS dumped its version banner in the 500 error response after a malformed `EXTRACTVALUE(1,CONCAT(0x7e,(SELECT version())))` payload. Indicates user input flows directly into a query without escaping. Mitigation: ORM query builder + remove debug error pages from production.
Union-based SQLi in admin login bypass
Critical. Login form accepted `' UNION SELECT 1,'admin','admin'-- -` and authenticated as the user in the second column. Indicates string concatenation in a SELECT-based authentication query. Mitigation: parameterized prepared statements + bcrypt password verification (never select on `password = '…'`).
Time-based blind SQLi in /api/feedback POST body
High (lower than confirmed because impact requires patience). `'; SELECT pg_sleep(5)-- -` reliably delays the response by 5s. Note: AuditCore disables `--technique=T` by default to avoid DB lock-up; this finding came from the heuristic ZAP scan, not full sqlmap exploitation.
Other injection & active tests scanners
FAQ
Why does AuditCore disable sqlmap's stacked-query technique?
Stacked queries (`; INSERT …; DROP TABLE …`) can write data to your database. We never want to risk that, even on a target the user owns. Stacked-query SQLi is rare on modern stacks anyway because most database drivers (PostgreSQL libpq, MySQL Connector/J, Node.js mysql2) disable multi-statement queries by default. If you specifically need stacked-query testing, run sqlmap manually against a staging copy.
Will sqlmap drop tables, exfiltrate data, or modify records?
Not in AuditCore's configuration. We use `--technique=BEU --risk=2 --level=3` and explicitly exclude data-dump flags (`--dump`, `--dump-all`, `--os-shell`). Detection only. If sqlmap finds an injection, it confirms exploitability with a single proof-of-concept query (e.g. `SELECT version()`) and reports it.
How long does the sqlmap phase take in an AuditCore scan?
Typically 5-15 minutes depending on target size. We crawl up to 100 URLs (Enterprise tier) and only invoke sqlmap on parameters that pass the ZAP heuristic. Targets with large parameter surfaces (e.g. monolithic search APIs) can push it to 30 minutes.
Can I exclude specific parameters from sqlmap testing?
Not currently via the UI — sqlmap testing scope is determined by the recording proxy + ZAP. If you have a parameter you know is unsafe to test (e.g. one that sends real-money transactions), don't include it in your authenticated crawl, or run AuditCore against a staging copy.
What's the difference between ZAP's active SQLi check and sqlmap?
ZAP's active scan is heuristic — it sends a few payloads per parameter and reports based on response patterns. Fast (~30s/URL) but with more false positives. sqlmap is a full exploitation engine — slower, but if it reports a finding, the vulnerability is confirmed (it produced data from the database). AuditCore runs both: ZAP first for breadth, sqlmap second for depth on flagged params.