SQL Injection: When User Input Becomes a Command
SQL injection tricks a database into running unintended commands by sneaking them into user input. It's a common attack on websites where user data is directly stitched into SQL queries. The footgun is trusting input; always use prepared statements instead.
Why it exists
Applications need to query databases based on user input, like finding a user by username. The vulnerability is born when developers create these queries by simply stitching text together, mixing the user's input directly into the SQL command string. This creates an opening for an attacker to change the command itself.
The mental model
Think of a SQL query as a Mad Libs puzzle. You have a template with blanks: "SELECT * FROM users WHERE username = '' AND password = ''". A normal user fills the blanks with their data. An attacker fills the blanks with data AND new puzzle instructions, like "' OR '1'='1'; --". The database, unable to tell the difference between intended data and malicious commands, executes the attacker's modified puzzle.
How it works
An attacker finds an input field, like a search bar, that feeds a database. Instead of entering normal data like 'jsmith', they enter a string containing SQL syntax. For example, entering "' OR 1=1 --" into a username field might change the query SELECT FROM users WHERE name = 'INPUT' to SELECT FROM users WHERE name = '' OR 1=1 --'. The OR 1=1 is always true, and -- comments out the rest of the original query, potentially bypassing password checks and returning all users.
When to use it
As a defender, you never "use" SQL injection. You defend against it. Security engineers and penetration testers, however, use it deliberately to find and demonstrate vulnerabilities in a controlled way so they can be fixed before a real attacker finds them.
When not to use it
As a developer, you must never write code vulnerable to SQL injection. The primary defense is not to manually filter "bad" characters (blacklisting), which is brittle. The correct and robust defense is to use parameterized queries, also known as prepared statements. These send the SQL command template and the user data to the database separately, ensuring data is never executed as a command.
One canonical example
Bypassing a login form. A backend might build a query like: query = "SELECT FROM users WHERE username = '" + username + "'". An attacker enters admin'-- for the username. The resulting query becomes SELECT FROM users WHERE username = 'admin'--'. The -- is a SQL comment, so the database executes only SELECT * FROM users WHERE username = 'admin', ignoring any password check that might have followed and logging the attacker in as the admin user.
Interview question
Which approach is considered the most robust defense against SQL injection attacks?
- a.Storing all sensitive user data in encrypted columns within the database.
- b.Implementing a comprehensive blacklist of known malicious SQL keywords and characters.
- c.Using parameterized queries, which send the SQL command and user data to the database separately.Correct
- d.Escaping all single quotes and double quotes in user input before constructing the SQL query.
Why? this is the answer
The card states that parameterized queries (prepared statements) are the "correct and robust defense" because they send the SQL command template and user data separately, ensuring data is never executed as a command. Options A and C describe manual filtering or escaping, which the card identifies as brittle and not the primary defense.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on sql — each one lists the topics its interview covers.
See open roles