Authorised SQL injection testing

SQL injection testing begins with a written boundary, not a command. Name the application, endpoints, accounts, time window, permitted techniques, data-handling rules, escalation contact, and stop conditions. If the target is not yours or explicitly in scope, do not test it.

What the instrument does

SQLmap automates detection of SQL injection behaviour across several database engines and injection techniques. That power makes it useful for controlled verification—and capable of damaging data, exhausting a service, or crossing into systems that were never authorised.

Treat every automatic action as a proposed change to the test plan. Start with the smallest request that can answer the question. Preserve the raw request, response, tool version, time, and environment so another authorised operator can reproduce the observation.

A safe field sequence

1. Reproduce manually. Capture the exact request and establish a clean baseline.
2. Minimise the test. Use a dedicated account and non-production data where possible. Begin with detection only.
3. Constrain the target. Specify the single parameter, request method, and known database type only when evidence supports it.
4. Record, do not collect. Prove exposure with the least sensitive result possible. A schema name or controlled marker is usually better evidence than a data dump.
5. Stop on boundary drift. Unexpected hosts, destructive prompts, service instability, or sensitive records are stop signals.
6. Verify the fix. Re-run the same minimal test and preserve both before-and-after evidence.

Example shape

python3 sqlmap.py -r authorised-request.txt \
  --batch \
  --level=1 \
  --risk=1

The request file should contain a captured request for the explicitly authorised application. Higher risk or broader enumeration is not a default next step; it requires a reason and, often, renewed approval.

What a useful finding contains

• the authorised asset and affected parameter;
• the smallest reproducible request;
• observed behaviour and confidence;
• realistic impact without exaggeration;
• redacted evidence;
• a remediation direction, such as parameterised queries;
• proof that the repair was tested on the real path.

This recovered note originally focused on tool features such as database dumping and tamper scripts. The durable lesson is narrower: automation is valuable only when scope, evidence, and restraint remain more authoritative than the tool.