SQL injection defense, part 2: finding and fixing injection flaws in your own applications

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

This is part 2 of our SQL injection defense series. The original version of this post published a list of third-party websites presented as targets for injection attacks — the kind of "target list" that serves no defensive purpose and puts real systems at risk. That list has been removed entirely and replaced with what actually protects applications: how to find injection flaws in systems you own, and how to fix them.

Never test systems you don't own

Scanning or probing a website for SQL injection without the owner's explicit permission is unauthorized access, and it is illegal in most jurisdictions — even if you never extract data and even if your motive is curiosity. There are no exceptions for "the site looked vulnerable" or "I was just testing." If you don't own it and don't have written authorization, don't touch it.

Learn and practice in legal labs

If you want to understand how injection works so you can defend against it, use environments built for that purpose. All of these are free, legal, and designed for learning:

• DVWA (Damn Vulnerable Web Application) — a deliberately vulnerable PHP application with graded difficulty levels, ideal for learning how injection manifests and how fixes change the behavior.
• bWAPP — a buggy web app with hundreds of vulnerabilities, including many injection variants, widely used in training courses.
• WebGoat — OWASP's intentionally insecure application with structured lessons on injection and other flaws.

Run these locally or in an isolated virtual machine — Docker makes this straightforward — never on shared or public infrastructure. Practice recognizing vulnerable code patterns, confirming flaws in the lab, and verifying that your fixes actually close them.

Finding injection flaws in your own applications

For systems you own or are authorized to assess, combine several approaches:

• Code review: search for SQL queries built by concatenating strings with user input. This is the root cause in the vast majority of cases. Review data-access layers, reporting endpoints, and legacy code first.
• Static analysis (SAST): run automated scanners in your CI pipeline to flag unsafe query construction before code ships.
• Dynamic testing (DAST) and authorized penetration tests: exercise the running application the way an attacker would, within the scope of your authorization.
• Bug bounty programs: if you run a public-facing application, a scoped bounty program lets vetted researchers report flaws to you instead of exploiting them.

Remediation that actually works

• Parameterized queries / prepared statements are the gold standard. User input becomes data, never executable SQL.
• Use a modern ORM or query builder with safe defaults, and avoid raw query methods unless you parameterize them.
• Least privilege: application database accounts should have the minimum permissions required. A reporting user does not need write access.
• Server-side input validation as defense in depth — never as the sole control.
• Generic error handling: never expose database errors to users; log them internally where your team can investigate.
• WAF and monitoring as compensating controls while code fixes are rolled out.

After fixing, re-test to confirm the flaw is closed, and add regression tests so it doesn't return in a future release.

If you find a flaw in someone else's system

Report it through the organization's responsible-disclosure or security contact channel. Do not demonstrate the impact, do not extract data, and do not publish details before the owner has had a reasonable chance to fix it.

Authorization reminder

All security testing must only be performed on systems you own or are explicitly authorized to assess. The labs listed above exist precisely so you can build these skills without ever touching a system that isn't yours.