/ Endolum Academy

SQL Injection Still Works in 2026

It has been over two decades since SQL injection was first documented. Companies still get breached by it. Here is how it works and how to actually prevent it.

tutorialweb-securitysql-injection

SQL injection was first formally described in 1998. Twenty-eight years later, it remains in the OWASP Top 10. Companies with billion-dollar security budgets still get popped by it.

This is embarrassing. Let us fix that.

How It Works (Quick Refresher)

SQL injection happens when user input becomes part of a database query without proper handling.

Vulnerable code looks like this:

query = "SELECT * FROM users WHERE username = '" + username + "'"

If a user enters admin' OR '1'='1 as their username, the query becomes:

SELECT * FROM users WHERE username = 'admin' OR '1'='1'

Since '1'='1' is always true, this returns all users. The attacker just bypassed authentication.

More dangerous payloads can extract data, modify records, or in some configurations, execute system commands.

Why It Still Happens

Legacy code. That PHP application from 2008 is still running because “it works” and nobody wants to touch it. Refactoring costs money. Getting breached costs more, but that is a future problem.

String concatenation is easy. Developers under deadline pressure take shortcuts. Building queries with string concatenation feels intuitive. Parameterized queries require slightly more thought.

ORMs are not magic. Object-Relational Mappers prevent most SQL injection by default, but developers can still write raw queries when the ORM feels limiting. Those raw queries often reintroduce the vulnerability.

Input validation confusion. Some developers think filtering input prevents SQL injection. It does not. Blacklisting dangerous characters is a game of whack-a-mole. Attackers have encoding tricks, alternative syntax, and infinite patience.

The Actual Fix

Parameterized queries. This is the answer. Not one answer among many. THE answer.

cursor.execute("SELECT * FROM users WHERE username = ?", (username,))

The database treats the parameter as data, never as code. No amount of creative input can change the query structure.

Every modern programming language supports this. Every database supports this. There is no excuse.

Stored procedures (with caveats). Stored procedures can help, but only if they also use parameterized inputs internally. A stored procedure that concatenates strings is just as vulnerable.

Least privilege. The database account your application uses should have minimal permissions. If your web app only needs to read from certain tables, its database user should not have write access to others. If you get breached, this limits damage.

Web Application Firewall. A WAF can catch obvious SQL injection attempts and buys time while you fix the actual vulnerability. It is not a substitute for secure code, but defense in depth matters.

Testing For It

Manual testing. Add a single quote to input fields and see what happens. Error messages that mention SQL syntax are a red flag. Applications should handle bad input gracefully, not expose database internals.

Automated scanning. Tools like SQLMap automate injection testing. Point it at a form and it will try hundreds of payload variations. Useful for finding obvious issues.

sqlmap -u "https://target.com/search?q=test" --dbs

Code review. Search your codebase for string concatenation patterns in database queries. Grep for common vulnerable patterns:

grep -r "SELECT.*+.*FROM" --include="*.py" .
grep -r "\$_GET\|$_POST" --include="*.php" . | grep -i "query\|sql"

Detection

If you cannot fix vulnerable code immediately, at least detect exploitation attempts.

Log analysis. SQL injection attempts often contain recognizable patterns: ' OR , UNION SELECT, --, /*. Monitor web server logs for these strings.

Database monitoring. Unusual queries stand out. A search function that suddenly runs UNION SELECT password FROM users is obviously malicious. Database activity monitoring tools can alert on query anomalies.

WAF logs. If your WAF blocks an injection attempt, investigate. Where there is one attempt, there are usually more. The attacker might find a bypass you did not anticipate.

Common Evasion Techniques

Attackers bypass basic filters using:

  • Case variation: SeLeCt instead of SELECT
  • URL encoding: %27 instead of '
  • Comments: SEL/**/ECT to break up keywords
  • Alternative syntax: CHAR(39) instead of a literal quote

This is why blacklisting fails. You cannot anticipate every encoding and variation. Parameterized queries sidestep the entire problem.

The Real Lesson

SQL injection is a solved problem. We have known the solution since 1999. The fact that it still works reflects organizational failures, not technical limitations.

If your application is vulnerable to SQL injection in 2026, the problem is not that attackers are clever. The problem is that someone chose speed over security, and nobody reviewed the code, and testing did not catch it, and monitoring did not detect attempts.

Security is a system. Single points of failure compound.

Want to practice finding and exploiting SQL injection in a safe environment? The Web Exploitation Expert course on Endolum Academy includes labs with real vulnerable applications. Break things, understand why they broke, learn to build them better.