You’re in a technical interview. The interviewer looks up from their notes and asks: “How would you protect a login form from SQL injection?” In that moment, your answer isn’t just about passing the interview — it’s about whether you understand one of the web’s most common security threats.
SQL Injection is when an attacker sneaks malicious input into a database query. Imagine a login form where you enter a username and password. Normally, the database should only check if those values exist. But if the code isn’t secure, an attacker could type something like admin' OR '1'='1. The database, confused, runs it as a valid command — and suddenly the attacker is logged in without ever knowing the real password.
More technically, SQL Injection happens when untrusted user input is placed directly inside an SQL query string. This breaks the separation between code and data, allowing attackers to alter the query’s logic — for example, turning a simple credential check into a query that returns every user in the database.
There’s a reason this topic keeps coming up in interviews: it’s not just theory. SQL Injection is still in the OWASP Top 10 after more than two decades, and a single overlooked query has cost companies millions in data breaches and lost trust.
💡 This article is the first in my Full-Stack Interview Prep series, where I break down common interview questions into simple explanations, real-world scenarios, and practical code examples in Go and Node.js. Each part of the series focuses on one core concept — from security topics like SQL Injection, XSS, and CSRF, to backend fundamentals like caching and authentication, and even frontend/system design essentials. My goal is to make these topics easier for developers preparing for interviews, while also showing recruiters how I approach teaching, collaboration, and writing clean, secure code.
What is SQL Injection? (Explained Simply)
Now that we’ve set the stage, let’s break down what SQL Injection really is — step by step, and in plain language.
Think of your SQL query as a conversation with the database. Normally, you ask a simple question like:
“Does a user named John exist with this password?”
But with SQL Injection, an attacker interrupts that conversation and sneaks in their own instructions. Instead of just typing John, they might type:
John' OR '1'='1 That small addition changes the meaning of the query. The database is tricked into thinking the condition is always true — which means the attacker could log in without knowing any real password.
Here’s a simplified SQL example to show what happens behind the scenes:
-- Normal query SELECT * FROM users WHERE username = 'John' AND password = 'secret'; -- Injected query SELECT * FROM users WHERE username = 'John' OR '1'='1' AND password = 'secret'; In the injected version, '1'='1' is always true. That makes the whole condition true, and the database happily returns a row — even if the password is wrong.
This is the essence of SQL Injection: when user input isn’t handled safely, it can alter the logic of a database query in dangerous ways.
SQL Injection in Practice (Bad Examples)
Let’s see how SQL Injection sneaks in through everyday code. These examples might look harmless, but they show what happens when user input is inserted directly into a query string.
Vulnerable Example in Go
// ❌ Vulnerable code query := "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'" rows, _ := db.Query(query) At first glance, this looks like a straightforward way to check if a user exists. But notice how we’re building the query by concatenating strings. That means whatever the user types in username or password gets injected directly into the SQL command.
Now imagine the attacker types this as the username:
admin' OR '1'='1 The query becomes:
SELECT * FROM users WHERE username='admin' OR '1'='1' AND password='whatever'; Since '1'='1' is always true, the database happily returns a row — and the attacker is logged in without knowing a real password.
Vulnerable Example in Node.js
// ❌ Vulnerable code const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`; db.query(query, (err, result) => { if (err) throw err; console.log(result); }); The same issue appears here. By embedding username and password directly in the query string, we’re giving attackers a chance to alter the logic.
If the attacker enters the same payload (admin' OR '1'='1), the query becomes:
SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = 'doesntmatter'; Again, the condition always evaluates to true, so the attacker bypasses authentication.
How to Prevent SQL Injection (Best Practices)
The good news is that SQL Injection is preventable. With a few best practices, you can protect your application — and your users — from this attack. Let’s walk through the most important defenses.
✅ Prepared Statements / Parameterized Queries
SQL Injection prevention starts with using prepared statements, sometimes called parameterized queries. Instead of directly inserting user input into a string, you pass the input as parameters. This keeps data separate from the query logic.
In Go (using database/sql):
// ✅ Safe code using parameters query := "SELECT * FROM users WHERE username=$1 AND password=$2" row := db.QueryRow(query, username, password) Here, $1 and $2 act as placeholders. The database ensures that username and password are treated as values, not code.
In Node.js (using mysql2):
// ✅ Safe code using parameters const query = "SELECT * FROM users WHERE username = ? AND password = ?"; db.query(query, [username, password], (err, result) => { if (err) throw err; console.log(result); }); The ? placeholders ensure the same protection. No matter what an attacker types, it will always be treated as data, never as part of the SQL command.
✅ ORMs & Query Builders
Another way to reduce risk is by using an ORM (Object-Relational Mapper) or query builder. Tools like GORM (Go) or Prisma (Node.js) abstract away SQL and usually handle parameterization for you by default.
Example:
// Prisma in Node.js const user = await prisma.user.findUnique({ where: { username: username }, }); ORMs aren’t foolproof, but they help developers write cleaner queries with safer defaults.
✅ Input Validation & Escaping
While prepared statements are your primary shield, it’s also good practice to validate input. For example:
- Ensure usernames only contain expected characters (letters, numbers).
- Validate that email fields actually look like emails.
This isn’t enough on its own — but combined with parameterization, it makes your app much harder to exploit.
✅ Principle of Least Privilege
Even with secure queries, you should avoid giving your database user more permissions than it needs. For example:
- Your application’s database account should not have rights to drop tables or manage users.
- Restrict it to just what the app needs:
SELECT,INSERT,UPDATE,DELETE.
This way, even if something goes wrong, the damage is limited.
Why Interviewers Ask This Question
So why do interviewers love asking about SQL Injection? It’s not just to check if you’ve memorized a definition. They use this question to see how you think, how you explain, and how you handle pressure.
Here are the main things they’re looking for:
🔹 1. Core Knowledge
Do you understand what SQL Injection is and why it matters? Interviewers want to confirm that you’re aware of common web vulnerabilities and can recognize insecure code when you see it.
🔹 2. Communication Skills
Can you explain the attack and its prevention clearly? Being able to walk through attack → defense in a way others can follow shows that you’re not only a good developer, but also someone who can mentor teammates and document your work.
🔹 3. Handling Pressure
Most interviewers won’t stop at a single question. They’ll push a little further to see if you can stay calm and keep your answers structured. For example, they might ask:
- “What’s SQL Injection?”
- “Can you give me an example in your favorite language?”
- “How would you prevent it in Go/Node?”
- “What happens if a company ignores this vulnerability?”
These follow-ups aren’t designed to trick you — they’re a chance to show that you understand the fundamentals and can adapt your answers.
Pop Quiz!
Before we wrap up, here’s a quick quiz to test your understanding. Don’t worry — this isn’t an exam. The goal is to practice, reinforce the concepts, and maybe even teach others by sharing your answers in the comments.
📝 Questions
1. Concept Check
What does the condition OR '1'='1 do when it appears in an SQL query?
2. True or False
Input validation alone is enough to completely prevent SQL Injection.
3.0. Fix the Vulnerable Code (Go)
Here’s a vulnerable Go query:
query := "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'" rows, _ := db.Query(query) How would you rewrite this using a prepared statement to make it safe?
3.1. Fix the Vulnerable Code (Node.js)
Here’s a vulnerable Node.js query:
const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`; db.query(query, (err, result) => { ... }); Rewrite it using parameterized queries to prevent injection.
💬 Try answering in the comments. Even if you’re not fully confident, writing out your thought process is one of the best ways to learn — and your answer might help another developer too.
Conclusion
SQL Injection is one of the simplest attacks to exploit, but also one of the simplest to prevent — as long as we use secure coding practices like prepared statements, validation, and proper permissions.
I’ll admit — early in my career, I wrote queries just like the vulnerable ones we saw earlier. It’s easy to do without realizing the risk. The important part is learning how to spot these mistakes and fix them before they reach production.
💬 Have you ever discovered SQL Injection risks in your own code? Share your experience in the comments — your story might help another developer catch the same mistake. And don’t forget to drop your answers to the quiz above; I’ll be checking in to give feedback.
👉 Next up in this series: XSS (Cross-Site Scripting) explained simply with Go & Node.js examples.
At the end of the day, secure coding isn’t just about passing interviews — it’s about protecting real people who trust us with their data.
Top comments (0)