SQL injection: how attackers exploit it, and how to test your own apps safely

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

The original post was a list of third-party websites the author claimed were vulnerable to SQL injection, presented as targets. That list is gone — deliberately. Publishing sites as attack targets is harmful, not educational. This rewrite covers the same vulnerability from the only side that matters now: how to find it in your own applications, how to fix it, and how to learn it safely.

How attackers exploit SQL injection (defender's view)

Attackers look for places where your application passes user input into a database query unsanitized. They probe by changing how the application responds — error messages, different result counts, timing differences. Once they confirm a flaw, they use it to read, alter, or delete data, or to pivot deeper into the network. From your side, the fingerprints are: odd characters in request logs, database errors echoed to clients, and queries requesting far more data than the page should display.

Test your own apps — legally

Never test this against someone else's site. Use purpose-built vulnerable applications that exist exactly for this:

• DVWA (Damn Vulnerable Web Application) — a deliberately vulnerable PHP/MySQL app you run locally, with adjustable difficulty levels.
• bWAPP (buggy Web Application) — hundreds of vulnerable scenarios, including multiple SQL injection flavors, in one local package.
• WebGoat — OWASP's interactive lessons on web flaws with guided fixes.

Run them in an isolated VM or Docker container, offline or on a closed network, and test only what you spun up yourself. Add SAST (static analysis) and DAST (dynamic scanning) tools to your own CI/CD pipeline for continuous, authorized coverage.

Finding SQL injection in your codebase

• Search for query strings built by concatenating variables — that's the pattern injection lives in.
• Review every place user input (URL parameters, form fields, headers, cookies) reaches the database.
• Check error handling: stack traces and DB errors shown to users hand attackers a roadmap.

Fixing it permanently

• Parameterized queries / prepared statements in every data-access layer — the root fix.
• Least-privilege database accounts: the web app's DB user should read/write only the tables it needs — never admin rights.
• Stored procedures and ORMs used correctly (with binding, not string interpolation) reduce exposure.
• A WAF and query monitoring as defense-in-depth: block known injection patterns and alert on anomalous query behavior — they don't replace fixing the code.
• Patch and review regularly so fixes don't regress in future releases.

Authorization disclaimer

All security testing must only be done on systems you own or are explicitly authorized to assess. Scanning or attacking real websites for SQL injection without written permission is illegal, even if your goal is "just to check."