SQL Injection: The 25-Year-Old Bug Still Emptying Databases

There's a famous webcomic where a mother names her son Robert'); DROP TABLE Students;--. When his school types his name into their database, the database obediently deletes all its student records. It's a joke, but it's also a perfectly accurate description of SQL injection — a vulnerability first documented in 1998 that is still one of the most damaging bugs on the web today.

What's actually going on

Most applications store their data in a database and talk to it using SQL — a language for asking questions like "give me the user whose email is this." The problem starts when the application builds those questions by gluing user input directly into the query text.

Say your login checks a user by writing a query that combines a fixed template with whatever the user typed into the email box. If the user types a normal email, fine. But if they type a carefully crafted string containing SQL syntax, they can change the meaning of the query itself — because the database can't tell where your intended command ends and the attacker's input begins. Sound familiar? It's the same root cause as XSS: mixing untrusted data into something that gets interpreted as code.

What an attacker gets

SQL injection isn't a minor bug. Depending on the query, an attacker can:

• Bypass authentication entirely — craft input that makes the login query always return "yes, this password is correct," logging in as any user, often the admin.
• Dump the entire database — read every user record, every password hash, every order, every private message.
• Modify or delete data — change balances, escalate their own privileges, wipe tables.
• In severe cases, take over the server the database runs on.

This is how a huge share of the historical mega-breaches happened — millions of accounts leaked at a time, very often traced back to one injectable query. It's not an exotic attack; automated tools scan the web for injectable parameters constantly.

Why it refuses to die

You'd think a 25-year-old, well-understood bug would be extinct by now. It isn't, for a few reasons:

• It only takes one missed query. A codebase can have a thousand safe database calls and one that glues input together — and that one is enough.
• ORMs lull people into safety. Modern frameworks use query builders that are safe by default, so developers forget the danger exists — until they drop down to a raw query "just this once" for something the ORM couldn't express.
• AI-generated code reintroduces it constantly. Ask an assistant to "write a function that looks up a user by name" and, unless you're specific, it will often produce string-concatenated SQL that works perfectly in a demo and is wide open in production. The code runs, the tests pass, and the vulnerability ships.

How to prevent it — for good

The fix has been the same for two decades and it's close to bulletproof: use parameterised queries (also called prepared statements).

Instead of building the query as one big string with the input baked in, you send the query and the data separately. You give the database a template with placeholders, then hand it the values. The database treats those values as pure data — never as SQL — so no amount of quote marks or SQL keywords in the input can change the query's meaning. The malicious name just becomes a (failed) search for a user literally called Robert'); DROP TABLE....

Beyond that:

• Prefer a well-maintained ORM or query builder and resist raw string queries.
• Apply least privilege to your database account — your app usually doesn't need permission to drop tables.
• Validate input as a secondary layer, but never rely on it as the primary defence; parameterisation is what actually saves you.

Safeey's role

SQL injection lives inside your code, so it's the natural territory of a code scanner (which is exactly why it's a headline check for the safeey-cli we're building). But its consequences leak outward: verbose database errors exposed on your live site, debug modes left on, and error pages that reveal your stack are all signals an attacker uses to find and exploit injectable queries. Safeey catches those outward-facing tells from the outside, so you close the reconnaissance doors while you fix the root cause.

Run a Safeey scan to find the information leaks that help attackers hunt for injection points.