SQL injection still alive in 2025 — real-world examples from our pentests
Yes, SQLi is still a thing in 2025.
From our last 20 web app pentests, 4 had exploitable SQL injection. All were custom-built applications.
Example (sanitized)
Login form POST parameter:
username=admin' OR 1=1--&password=anything
The app concatenated user input directly into the SQL query:
SELECT * FROM users WHERE username = '$input' AND password = '$password'
Why it's still happening
- Legacy code that nobody wants to refactor
- Developers who learned SQL in 2005 and never updated their practices
- No code review or SAST in the pipeline
- "It's internal only" mentality (until it's not)
Prevention
- Parameterized queries / prepared statements — there is no excuse not to use them
- Input validation (whitelist, not blacklist)
- WAF as defense in depth (not primary protection)
- SAST/DAST in CI/CD — catch it before production
The "it's internal only" excuse is the one I hear most. Then the VPN gets compromised, or an employee goes rogue, and suddenly your internal app is the crown jewels.
For Python devs: if you're using raw cursor.execute(f"SELECT * FROM ..."), you're doing it wrong. Use parameterized queries: cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,)).
We added SQLMap to our automated pentest pipeline. It runs against every deployment. Found 2 SQLi issues that manual testing missed because they required specific parameter encoding.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access