Sql Injection

By the end of this lesson you'll understand exactly how SQL injection turns user input into runaway SQL — and you'll be able to shut it down with parameterised queries , allow-lists, and least-privilege accounts. This is the single most important security skill in all of databases.

Learn Python, JavaScript, Java and more with free interactive lessons, real projects and AI-powered help. Beginner-friendly.

Part of the free SQL course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

The attacks in this lesson target a login that reads from this users table. Notice that row 1 is the admin — that matters, because a bypass logs the attacker in as the first matching row.

SQL injection happens when user input gets glued directly into a query string, so the database can't tell your code apart from their text . It's the top web vulnerability on the OWASP list — and it's 100% preventable.

Imagine dictating a form letter to an assistant: "Dear ___, ...". You expect a name. But the visitor says "Bob. Also, shred every file in the cabinet." If your assistant blindly writes down everything, the extra sentence becomes an instruction. A concatenated query is that gullible assistant — and the quote character ' is how the attacker ends the "name" and starts dictating commands.

Below is the vulnerable pattern. The nameInput isn't a value to the database — once it's pasted into the string, it's part of the SQL itself.

Now watch what a single quote does. The attacker's text closes the string early, adds OR '1'='1' (true for every row), and uses -- to comment out the rest of your query.

The same hole lets an attacker stack a whole new statement after a semicolon — including a destructive one like DROP TABLE — or bolt on a UNION SELECT to siphon data out of an unrelated table.

Fill in the blanks to explain the flaw and to show exactly what input breaks this concatenated query. The expected answer is in the comments so you can self-check.

A parameterised query (also called a prepared statement ) splits the SQL from the data. You write the query with a placeholder — ? , $1 , or :name depending on your engine — and hand the value over separately. The database compiles the query first , then slots your value in as pure data. Quotes in the input can no longer "escape" into the SQL, because the SQL is already finished.

Want to see the separation? PostgreSQL exposes it directly with PREPARE and EXECUTE : the plan is built once, and every value you pass afterwards is bound into a typed hole.

Take the same vulnerable login and make it safe by replacing the concatenation with a parameter placeholder. One blank — use ? (or $1 / :email ).

Parameters are the fix — but good security stacks layers, so a single mistake isn't fatal. The catch: you can never bind a table or column name as a parameter. For those, validate against an allow-list (a fixed set of names you accept). Escaping input by hand is a brittle last resort — get it wrong once and you're exposed.

Assume an attack might one day slip through. The login your app connects with should only be able to do the app's job — no DROP , no ALTER , no superuser. Then even a successful injection runs into permission denied for the worst operations.

An ORM (Object-Relational Mapper — the library that turns objects into SQL, like Django, SQLAlchemy, ActiveRecord, or Prisma) parameterises for you by default, which is a big part of why ORMs are safer. But every ORM has a raw SQL escape hatch, and the moment you use it you're back to manual safety. Stored procedures aren't automatically safe either: if a procedure builds SQL from concatenated text and runs it with EXECUTE , it's just as injectable.

Placeholder style varies ( ? , $1 , :name , %s , @id ) but the rule is the same everywhere: SQL with a placeholder, value passed separately.

Q: If I parameterise everything, do I still need input validation?

Yes — as a second layer. Parameters stop injection in values , but they can't protect a table or column name you build dynamically, and validation enforces business rules (length, format). Use both; never let validation be your only defence.

Don't. Hand-escaping is notoriously easy to get wrong — character sets, Unicode look-alikes, and numeric contexts all create holes. A parameterised query is simpler and safer, so reach for escaping only as a genuine last resort.

Q: Are stored procedures automatically safe from injection?

No. A procedure that builds a query by concatenating strings and runs it with dynamic EXECUTE / EXEC is just as injectable as application code. Use parameters inside the procedure too ( EXECUTE ... USING ).

Q: My ORM builds the SQL for me — am I covered?

Mostly. ORMs parameterise normal queries by default, which is great. The risk is the raw SQL escape hatch: an f-string or string concatenation passed to .raw() / .query() bypasses that protection. Always pass values as parameters, even in raw queries.

Put it all together — a brief, a blank canvas, and the expected shape in the comments. Make the two-field login injection-proof, then sanity-check it in a playground.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary