SQL injection is older than some of the engineers shipping it today. It was written up publicly back in 1998. It is still sitting on the OWASP Top Ten. Let that sink in. We have had more than two decades to kill this bug, and it is still in production, right now, inside apps people trust with their money.
I have a penetration-testing background. SQL injection is often the first thing I reach for on a login form, not because I am clever, but because it still works far too often.
Let me explain the concept, because once you see it you cannot unsee it.
Your query is a sentence, and user input is a word in it
A database query is just a command written in a language called SQL. "Give me the user whose email matches this." Simple enough.
The trouble starts when a developer builds that command by gluing strings together. They take the sentence, cut a hole where the user's input goes, and paste whatever the user typed straight into the hole.
Here is the mental model. The database does not know where your trusted sentence ends and the user's untrusted input begins. To the database, it is all one string. One command. So if an attacker types something that reads like SQL instead of reading like a name, the database happily treats it as part of the command.
That is the whole trick. Input that was meant to be data gets executed as code. The user stopped answering your question and started giving the database new orders.
I will not hand you a working payload. You do not need one to understand the danger. Just picture a login box where the "password" field quietly rewrites the question from "is this password correct" into "log me in no matter what." Same mechanism. Different sentence.
Why it refuses to die
Because string concatenation feels natural. You need a dynamic query, you have a variable, you add them together. It reads fine. It passes a code review from someone who is tired. It works perfectly in testing, because testers type names, not commands.
It also hides in the boring corners. An old reporting endpoint. A search filter someone bolted on during a Friday rush. A legacy service nobody wants to touch. The shiny new parts of your stack are usually fine. The ten-year-old admin panel is where I go hunting.
The fix is boring, and boring is good
Parameterized queries. Also called prepared statements. This is the one that matters.
Instead of gluing input into the sentence, you send the command and the data separately. You tell the database, "here is the query, and here are the values, and the values are values, do not read them as commands." The database keeps the two apart. The hole is sealed. Input can never cross back into code.
In practice:
- Use parameterized queries or prepared statements everywhere. No exceptions for "just this one small query."
- Let a mature ORM build your queries for you. They parameterize by default.
- Never concatenate user input into a query string. Not for ids. Not for sort order. Not ever.
- Apply least privilege to the database account, so one mistake stays contained.
ORMs help, until you hand them a loaded gun
Here is the part people miss. An ORM protects you right up until you drop into its raw-query escape hatch and start concatenating again. Most ORMs have one. Most teams use it. That raw string is exactly where the injection sneaks back in.
So the rule holds even inside your safe framework. Pass values as parameters. If you find yourself building a query by adding strings together, stop, no matter which tool you are in.
SQL injection is not a hard problem anymore. The fix has existed for as long as the bug has. We keep shipping it because we keep taking the shortcut. Write the parameterized query. It costs you three extra seconds, and it is the difference between a database and a crime scene.
I am Ksatria Bintang Samudra, an AI-native full-stack engineer with a penetration-testing background and a deep interest in digital forensics, open to remote work worldwide. More of what I build at ksatriabintangsamudra.com.
Top comments (0)