SQL Injections

Have you ever tried logging into a website and been met with a curt "incorrect login details"? Maybe it's been a while and you can't remember which one you fumbled: the username or the password. Wouldn't it help if the site just told you which was wrong? It's frustrating, sure. But that vagueness is deliberate. It's there to keep the bad guys out. Except, as we're about to see , that very same message can sometimes let them in.
That deliberate ambiguity prevents an attacker from working out which of your credentials is correct, and stops them from quietly scanning the system for valid accounts. It defends you on two fronts.

The first is user enumeration. If a site helpfully announces "that username does not exist," an attacker can feed it thousands of names in succession and note which ones don't trigger that message, mapping out exactly who holds an account on the site.

The second is password guessing. The moment a form confirms "the username is correct, but the password is wrong," the attacker has locked onto a confirmed target. Half the puzzle is solved; now they only need the password.

The tale of two security guards

Picture a thief loitering outside a secure apartment building, intent on breaking into one specific unit and the only way in is past the guard at the desk.

The bad guard (a detailed error). The thief says, "I'm here to see John Henry in 4A, and the passkey is 'Apple99'." The guard replies, "John Henry lives here, but that's the wrong key." In one careless sentence, he's confirmed that John Henry is a resident and narrowed the thief's task to a single unknown: the key.

The good guard (a vague error). Same thief, same request. But this guard is switched on. He simply says, "Access denied." Nothing more. The thief is left in the dark. No idea whether John Henry even lives there, or whether it was the key that failed. Every door remains a mystery.

That single-sentence difference is the entire philosophy behind a well-designed error message.

Why your account gets locked out

You've probably noticed that too many failed attempts will freeze you out of your account for a while. That isn't the system sulking or refusing to talk to you, it's a deliberate defence against brute-force attacks, where automated software machine-guns thousands of password combinations at a login form in the hope that one lands. It also blunts password spraying, a quieter cousin in which attackers try a handful of common passwords across many accounts at once. Lock the door after a few wrong knocks, and both tactics fall apart.

Why databases matter

Before we get to the fun part, a quick detour into what sits behind the login box.

Every interactive website has a backend: the behind-the-scenes engine that remembers things. When you log into an online shop and see your past orders, your saved cart, and your profile, all of that is being retrieved from a database.

Think of a database as an enormous, meticulously organised filing cabinet. Every time you log in, the website walks over to that cabinet and asks a question: "Do you have a customer with this username and this password?" If the cabinet says yes, you're in.

The language the website uses to pose those questions is SQL (Structured Query Language). A typical question, a query, reads almost like plain English:

Find me the user whose username is adam_admin and whose password is hunter1.

Hold onto that sentence. Everything that follows hinges on it.

Did someone say injections?!

This is where SQL injection enters the story. Yes — an odd, almost medical name for a hacking technique. I found it amusing too. But trust me: it's as ingenious as it is dangerous in the wrong hands.

In essence, SQL injection is when an attacker slips malicious code into a website's input form to trick the database into running commands it was never meant to run. Done right, it lets them stroll past login screens, siphon out private data, or wipe entire tables clean.

Picture ordering a coffee. Vanilla latte, iced cap, matcha or whatever tickles your fancy. Normally you say, "I'll have a vanilla latte," and the barista hands you a vanilla latte. Simple.

Now imagine you say, "I'll have a vanilla latte, and also open the till and hand me all the cash." A poorly trained barista (much like an insecure website) doesn't stop to question the second half. They obey the whole sentence as a single instruction, blind to the fact that half of it should never have been carried out.

That's the crux of it. The website can't tell the difference between what you typed and the instructions it gives its own database. So an attacker types a few carefully chosen characters that rewrite the question into something far simpler: just find this user, and never mind the password. And the site waves them straight through, never having known the real password at all.

It works not because it's sophisticated, but because the site trusted a user's input as though it were its own command. And, as we'll see, the fix is simply to keep the two strictly apart.

The break-in,

Normally the site builds a query like find a user where username is adam_admin and password is hunter1, both halves must be true, so a wrong password means no entry. The problem is the site pastes whatever you type straight into that sentence. So the attacker types adam_admin'-- into the username box: the apostrophe closes the username off early, and the -- tells the database to ignore everything after it as a mere comment , which happens to include the entire password check. The database is left with a much simpler question. Just find a user called adam_admin , and since that user exists, it opens the door, logging the attacker in without them ever knowing the real password.

So how do you keep the bad guys out?

Here's the reassuring part. For an attack this notorious, the defences are remarkably well understood.

If you write the code:

• Use parameterised queries (also called prepared statements). This is the single most important fix. Instead of gluing user input into your SQL sentence, you send the command and the data down separate channels, so the database always knows which is which. Typed input can never become part of the command and the apostrophe trick simply stops working. Every mainstream language and framework supports this out of the box.
• Treat every input as hostile. Validate and sanitise anything a user can type, and assume it's an attack until proven otherwise.
• Keep your error messages vague. One generic "incorrect username or password" for every failure. Don't confirm which half was wrong, that's the very door we opened at the start of this post.
• Give the database the least privilege it needs. The account your website uses to talk to the database shouldn't be an all-powerful admin. Grant it only what it genuinely requires, so a breach does less damage.

If you run a site but don't write the code:

• Ask your developer or platform one blunt question: "Are we protected against SQL injection using parameterised queries?" A confident, specific answer is a good sign. A blank stare is a red flag.
• Stick to reputable, actively maintained platforms and actually install those updates. Most breaches exploit holes that already had a fix waiting.
• Collect as little sensitive data as you can. You can't leak what you never stored.

The takeaway

SQL injection endures not because it's clever, but because it's so easy to leave the door ajar and so easy to overlook. An attacker doesn't need special access or stolen secrets. They just need a website that can't tell the difference between a user's words and its own instructions.

The defence is equally unglamorous: treat input as data, never as commands; say less in your error messages; and keep the two strictly apart. Do that, and the apostrophe stays exactly what it was always meant to be , a harmless little punctuation mark.

Because sometimes, that really is all it takes to break in: one apostrophe and a couple of dashes.

I am trying to make more blog posts especially around cyber security so please let me know your thoughts about this. I would love to hear feedback on how you guys found this and any other topics you may be interested in.