SQL Injection in 2026: It's Still Happening and Here's Why Your Sanitization Isn't Enough

I want to start with something that happened to a project I was reviewing last year. The developer had built a reasonably solid PHP backend — proper folder structure, decent separation of concerns, password hashing done right. But buried inside one of the admin controllers was this:

$search = $_GET['q'];
$result = $db->query("SELECT * FROM users WHERE username LIKE '%" . $search . "%'");

One line. That's all it takes. The rest of the application was fine. But that one input going straight into a query string meant the entire user database was readable to anyone who knew what they were doing.

The developer wasn't careless. They had used prepared statements everywhere else. This one just slipped through because it felt "read-only" — just a search, what's the worst that could happen? Quite a bit, as it turns out.

That's the thing about SQL injection that trips people up in 2026. It's not that developers don't know what it is. Most do, at least roughly. The problem is the exceptions — the places where the usual pattern breaks down, where a developer makes a judgment call and gets it wrong.

What SQL Injection Actually Does

At its core, SQL injection happens when user-controlled input becomes part of a SQL query without being properly separated from the query structure. The database engine can't tell the difference between your intended query and instructions an attacker smuggled in through your input field.

The classic example everyone shows in tutorials:

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

Type ' OR '1'='1 into a login form backed by a naive query and you're authenticated as the first user in the database. No password needed. It's a party trick at this point, but the underlying mechanism is what matters — and that mechanism shows up in much less obvious ways than a login form.

Here's a more realistic example from a Telegram bot panel I've seen more than once. The bot lets users check their balance by sending a command with their ID:

// User sends: /balance 42
$user_id = $message['text']; // "42" — looks safe enough
$stmt = $db->query("SELECT balance FROM accounts WHERE id = " . $user_id);

An integer looks harmless. No quotes, no string weirdness. But what if the user sends 42 UNION SELECT token FROM admin_sessions--? Now your query returns the session token from the admin table alongside the balance. And if your bot echoes the query result back to the user — which many simple bots do — you've just handed over admin credentials.

This is why "it's just a number" isn't a safe assumption. It needs to be a parameterized number, not a concatenated one.

The Sanitization Trap

The most common false sense of security I see is relying on mysqli_real_escape_string() or similar escaping functions instead of prepared statements. A lot of older PHP tutorials taught this pattern, and it ended up deeply embedded in codebases that have been copy-pasted and iterated on for years.

The problem is that escaping is context-dependent and fragile in ways that parameterization isn't.

Escaping works by adding backslashes before characters that would break out of a string context — quotes, mostly. But it only works correctly if you're inside a string context to begin with. If your value goes into a query without quotes around it — like an integer field, or an ORDER BY clause, or a table name — escaping does nothing useful:

// Escaping does nothing here — there are no quotes to escape out of
$order = mysqli_real_escape_string($conn, $_GET['sort']); // user sends: id DESC; DROP TABLE users--
$query = "SELECT * FROM products ORDER BY " . $order;

The escape function can't help you there because the attack doesn't need quotes. The value is being inserted directly into the SQL structure, not into a quoted string literal.

Prepared statements solve this at the protocol level. The query structure and the data are sent to the database separately. The database engine receives them as distinct things and never tries to parse your data as SQL. There's no character to escape because the data literally never gets concatenated into query text.

// This is safe regardless of what $order contains
$stmt = $pdo->prepare("SELECT * FROM products WHERE category = ?");
$stmt->execute([$_GET['category']]);
$results = $stmt->fetchAll();

One important note: prepared statements can't parameterize table names, column names, or SQL keywords. If you need dynamic column sorting (ORDER BY user-chosen column), you have to use a whitelist approach — not escaping, not parameterization, a literal allowlist:

$allowed_columns = ['price', 'name', 'created_at', 'popularity'];
$sort = in_array($_GET['sort'], $allowed_columns) ? $_GET['sort'] : 'created_at';
$stmt = $pdo->prepare("SELECT * FROM products ORDER BY {$sort} ASC");
$stmt->execute();

The whitelist approach here is correct because you're choosing from a fixed set of values you control. The user's input is used only as a selector, not as the value itself.

Second-Order Injection — The One That Bites Senior Developers

First-order injection is what most people picture — input comes in, goes into a query, attack happens. Second-order injection is more interesting and honestly more dangerous because it bypasses a lot of mental models about "safe" data.

Here's how it works: an attacker registers with a username like admin'--. Your registration code uses a prepared statement, so it gets stored safely in the database — the string literally stored is admin'--, apostrophe and all. No injection happens at write time.

Later, a different part of the application retrieves that username from the database and reuses it in a query without parameterizing it, because a developer assumed that data from the database is safe:

// Retrieving the username from DB — this comes back as: admin'--
$username = $row['username'];

// Later, somewhere else in the codebase:
$query = "UPDATE user_logs SET last_seen = NOW() WHERE username = '" . $username . "'";

The single quote in the stored username breaks out of the string context. The -- comments out the rest of the query. Depending on the application, this could be used to modify records, bypass checks, or extract data.

The fix is simple to state but requires discipline to apply consistently: data from the database is not safe to concatenate into queries. It went into the database through user input at some point. Always parameterize, regardless of whether the data came from a user form five seconds ago or from the database ten minutes ago.

Blind SQLi — When There's No Error Output to Help You

Most tutorials demonstrate SQL injection using error messages — the database throws an error and you can see what went wrong. In production applications, you should have display_errors = Off, so attackers can't rely on error output. But that doesn't make the application safe — it just changes the technique.

Blind SQL injection works by asking the database yes/no questions and inferring information from whether the response changes. Boolean-based blind injection changes the query logic to return different results depending on whether a condition is true:

-- Does the first character of the admin password hash start with 'a'?
/products?id=1 AND SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)='a'

-- If the page loads normally: yes
-- If the page loads differently (empty, error, redirect): no

An attacker runs this systematically, one character at a time, across the entire hash. Tools like sqlmap automate this completely — they can dump an entire database through a single injectable parameter, even with no error output, by sending thousands of carefully crafted requests.

Time-based blind injection is similar but uses query execution time as the signal instead of response differences:

-- If admin password starts with 'a', wait 5 seconds
/products?id=1; IF(SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a', SLEEP(5), 0)--

If the response takes 5 seconds, the condition is true. This works even when the application returns identical output regardless of the query result.

This is why "we don't show errors" isn't a defense — it's a good practice for other reasons, but it doesn't stop a motivated attacker from extracting your data character by character.

A Realistic Defense Checklist

There's no single magic fix, but the combination of these four things handles the overwhelming majority of SQL injection scenarios:

1. Use prepared statements for everything, without exception. Not "for user inputs." For everything. Every query that has any variable in it. Make it a habit so automatic that the thought of string concatenation in a query feels uncomfortable.

2. Use a database user with the minimum permissions your app actually needs. Your web application almost certainly doesn't need DROP TABLE permissions, or the ability to read from system tables, or write access to tables it only reads from. If an injection does happen, limited DB permissions dramatically constrain what the attacker can do.

-- Create a restricted user for your app
CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'strong_password';
GRANT SELECT, INSERT, UPDATE ON your_database.* TO 'app_user'@'localhost';
-- No DROP, no DELETE on sensitive tables, no access to information_schema
FLUSH PRIVILEGES;

3. Never trust data from the database in new queries. Treat data retrieved from storage the same way you treat data coming in from a form. It had a user at the other end at some point.

4. Use a WAF as a supplementary layer, not a primary defense. Cloudflare's WAF, for example, will catch a lot of common injection patterns in GET parameters. It's useful backup, but it shouldn't be what stands between your database and an attacker — your code should be.

Testing Your Own Application

The most useful thing you can do right now is open your codebase and search for every instance of $db->query(, mysqli_query(, or any raw query execution, and check what's being concatenated into it. Not what you think is being concatenated — what's actually there.

For a more thorough test, run sqlmap against a staging environment of your own application. Point it at your login form, your search endpoints, your API parameters:

sqlmap -u "https://staging.yoursite.com/search?q=test" --dbs --level=2

If it finds something, you want to know about it now rather than after someone else does. sqlmap is the same tool an attacker would use — running it on your own app is one of the most honest security checks you can do.

If you're building a Telegram bot or a PHP panel and want to audit your query handling before going live, it's worth doing a manual review of every endpoint that accepts user input and traces it to a database operation. It takes a couple of hours and the list of things you find will surprise you.

The Real Reason It Still Happens

SQL injection isn't still in the OWASP Top 10 because developers are bad at their jobs. It's there because codebases have history. A prepared statement written carefully in 2024 sits in the same file as code that was copy-pasted from a 2015 Stack Overflow answer. Deadlines push shortcuts. New developers join projects and adopt the existing patterns without questioning them. Legacy code never quite gets the refactor it needs.

The goal isn't a perfect codebase from day one. It's building habits — and occasionally auditing — so that when something slips through, you find it yourself before it becomes a problem.

Write parameterized queries. Check your old ones. Run a scan against your own staging environment once in a while. That's genuinely it.

— Skand K.