How to Use SQLmap: Practical Guide with Examples

In one line

SQLmap is a tool that automatically finds and exploits SQL injection for you, then pulls the database apart, once you have understood how the attack works by hand.

What this is, for a beginner

SQLmap automates the detection and exploitation of SQL injection. Once you have found or suspect an injectable parameter, SQLmap can confirm it, identify the database, enumerate its structure, and extract data, handling the fiddly details of different injection techniques and database systems for you. It is powerful, which is exactly why you should understand manual SQL injection first, so you can direct it and trust its results.

The workflow is straightforward: give SQLmap a request that includes the parameter to test, let it detect the injection, then progressively enumerate databases, tables, and columns before dumping the data you want. Against a lab you own, this shows how quickly an unparameterised query turns into full database disclosure.

The legal lab we use: DVWA

Run SQLmap only against your own local DVWA or another lab you own. Automated exploitation of systems you do not own is illegal.

DVWA project page →

Full walkthrough: exploiting it step by step

Step 1 — Capture an authenticated request

DVWA needs a session, so capture a request to the injectable page including your cookie, either by copying it from the browser or saving it from Burp to a file.

saved request (request.txt)

GET /vulnerabilities/sqli/?id=1&Submit=Submit
Cookie: PHPSESSID=...; security=low

Expected result: You have a full request, including the session cookie, that reaches the injectable id parameter.

Step 2 — Point SQLmap at the parameter

Run SQLmap against the request, telling it which parameter to test. It probes the parameter and reports whether it is injectable and by which techniques.

terminal

sqlmap -r request.txt -p id --batch

Expected result: SQLmap confirms the id parameter is injectable and names the techniques and back-end database it detected.

Step 3 — Enumerate databases

Ask SQLmap to list the databases available, the first step of mapping what data is reachable.

terminal

sqlmap -r request.txt -p id --dbs

Expected result: A list of database names is returned, including the application's own database.

Step 4 — Enumerate tables and columns

Drill into the application database to list its tables, then the columns of the interesting one, such as a users table.

terminal

sqlmap -r request.txt -p id -D dvwa --tables
sqlmap -r request.txt -p id -D dvwa -T users --columns

Expected result: The tables in the database and the columns of the users table (such as user and password) are listed.

Step 5 — Dump the data

Finally, extract the contents of the target columns. SQLmap can also attempt to crack recovered password hashes with a wordlist.

terminal

sqlmap -r request.txt -p id -D dvwa -T users -C user,password --dump

Expected result: The usernames and password hashes are dumped, and SQLmap offers to crack the hashes, completing the end-to-end extraction.

Free resource

Get the free 35-week ethical hacking roadmap

The exact order I'd learn this in, every vulnerability and tool, week by week, with the labs to practise each one. Enter your email and I'll send it over, plus one practical lesson each week.

How to detect and fix this

How to detect it

SQLmap generates many similar, anomalous requests to a parameter; rate limiting, anomaly detection, and web application firewalls can flag or slow it.
The underlying vulnerability is confirmed by the same manual tests SQLmap automates, so any injectable parameter it finds is a real finding to fix at the source.
Database errors and unusual query patterns in logs are signals worth monitoring.

How to fix it

Fix the injection itself with parameterised queries; once input can never become SQL, SQLmap has nothing to exploit.
Apply least privilege to the application's database account so extraction is limited even if a flaw slips through.
Add a web application firewall and monitoring as defence in depth, not as a substitute for parameterised queries.
Review code for string-built queries, which are the root cause SQLmap thrives on.

Common beginner mistakes

Running SQLmap without understanding manual injection, then misreading results or missing context.
Forgetting the session cookie, so SQLmap tests an unauthenticated page and finds nothing.
Using aggressive settings that hammer a fragile lab; start gentle and increase only as needed.
Pointing SQLmap at any system you do not own, which is illegal; keep it to your own labs.

FAQ

Should beginners use SQLmap?

Use it after you understand manual SQL injection, not instead of learning it. SQLmap automates the tedious extraction, but without the underlying knowledge you cannot direct it well, validate its findings, or explain the impact. Learn by hand first, then let the tool speed you up.

Why does SQLmap need the cookie?

Because the injectable page in DVWA and many real apps requires an authenticated session. Without the session cookie, SQLmap requests an unauthenticated page and never reaches the vulnerable parameter, so it appears to find nothing.

Can SQLmap crack the passwords it finds?

It can attempt to crack recovered password hashes using a wordlist, and it will offer to do so after a dump. For serious cracking you would move the hashes to a dedicated tool like John the Ripper or Hashcat.

Where to go from here

You just exploited one vulnerability in a lab. Here's the structured path.

Scattered tutorials teach you tricks; they don't make you a pentester. My mentorship is 35 weeks of exactly this, every vulnerability and tool in a deliberate order, on real labs, with one-on-one feedback on your work so your mistakes get caught early instead of becoming habits.

See the mentorship

Keep practising

How to Exploit SQL Injection How to Use Burp Suite How to Use John the Ripper