Detailed explanation
SQL injection occurs when untrusted input becomes part of a SQL statement's executable syntax instead of remaining data. It commonly happens when an application builds queries by concatenating strings. For example, constructing SELECT * FROM users WHERE email = '<input>' allows a crafted value such as ' OR '1'='1 to turn the filter into a condition that matches every row. Depending on the query, database permissions and driver behaviour, an attacker could read confidential records, bypass authentication, modify data or delete records. Injection can also enter through cookies, headers or previously stored values, not just form fields.
The primary defence is parameterised queries, usually exposed through a database driver's prepared-statement or parameter-binding API. Write the SQL structure with placeholders, then supply values separately: SELECT * FROM users WHERE email = ?. The driver and database handle the bound value as data, so quotes or SQL keywords inside it cannot become additional query syntax. Placeholder styles vary: some libraries use ?, others use $1 or named parameters. Preparing a statement alone is insufficient if attacker-controlled text was already concatenated into it; the important step is binding untrusted values rather than inserting them into SQL text.
Parameters normally represent values, not table names, column names or keywords such as ASC and DESC. For dynamic sorting or table selection, map accepted user choices to a small, fixed allowlist of SQL fragments defined by the application. Validate types, lengths, ranges and business rules as an additional safeguard, but do not treat validation or manual quote escaping as a replacement for parameter binding. ORMs and stored procedures are safe only when their queries follow the same rule; raw SQL and dynamically concatenated statements can still be vulnerable.
Use a least-privilege database account so the application has only the permissions its features require, not administrative access. Keep detailed database errors out of client responses, log failures securely and review every place that constructs SQL. Interviewers look for a clear distinction between preventing injection through parameter binding and limiting its impact through permissions, along with awareness that all untrusted inputs require consistent handling.
Key points to remember
- SQL injection lets untrusted input alter a query's executable structure.
- Use placeholders and bind values separately through the database driver.
- Use fixed allowlist mappings for dynamic identifiers and sort directions.
- Apply input validation and least-privilege access as additional safeguards.
- Audit ORM raw queries and stored procedures for unsafe dynamic SQL.
Common mistakes candidates make
- Assuming a prepared statement is safe even when input was concatenated before preparation.
- Relying on manual escaping, keyword blacklists or input validation instead of parameter binding.
- Assuming ORMs and stored procedures automatically prevent SQL injection.
Likely follow-up questions
Can a parameter replace a table name or an ORDER BY column?
Parameters generally bind values, not SQL identifiers or syntax. Map the requested table, column or sort direction to predefined SQL fragments using a strict allowlist.
Are stored procedures always safe from SQL injection?
No; a stored procedure can still concatenate input into dynamic SQL. Use static statements with parameters or parameterise any dynamic SQL using the database's supported API.
What is blind SQL injection?
Blind SQL injection occurs when query results or detailed errors are not directly visible to the attacker. Information can still be inferred from changes in application behaviour or response timing, so hiding errors alone does not prevent injection.
Interview tip: Start with the code-versus-data distinction, contrast concatenation with parameter binding, then mention allowlists and least privilege.