Sample questions
As Injection Input ValidationDifficulty 1
One query builds SQL by concatenating a username directly into the string: "SELECT FROM users WHERE name = '" + name + "'". Another uses a parametrized query: "SELECT FROM users WHERE name = ?" with name bound separately. Why is the second one safe against SQL injection?
- aIt runs faster, so an attacker has no time to inject anything
- bThe database only accepts queries shorter than the first form
- cThe bound value is sent as data, never parsed as SQL syntax✓
- dPlaceholders automatically strip all quote characters
Explanation:With a parametrized query, the SQL text and the parameter values travel to the database separately; the driver binds name as a literal data value, so characters like ' inside it can never change the query's structure. Concatenation instead builds the SQL text itself from untrusted input, letting an attacker close the string and add their own clauses.
As Injection Input ValidationDifficulty 2
An application uses an ORM's query builder for most queries, but one report endpoint calls db.raw("SELECT * FROM orders WHERE status = '" + status + "'") to build a dynamic filter. Does using an ORM elsewhere protect this endpoint from SQL injection?
- aNo,
.raw() with string concatenation bypasses the ORM's parameter binding entirely✓ - bYes, the ORM's connection pool sanitizes every string before execution by stripping any character sequence that resembles SQL syntax
- cYes, ORMs reject any query containing user-supplied text
- dNo, but only if the table has more than one column
Explanation:ORMs prevent SQL injection by binding parameters for you when you use their query-building API. Dropping down to a raw SQL escape hatch and concatenating untrusted input reintroduces the exact same vulnerability as hand-written SQL — the ORM label on the rest of the codebase provides no protection to this one query.
As Injection Input ValidationDifficulty 2
A team moves query logic into a database stored procedure to "get away from string-built SQL in application code." Inside the procedure, the parameter is still concatenated into a dynamic SQL string with EXEC(@sql). Is the stored procedure immune to SQL injection?
- aYes, stored procedures always run with reduced database privileges
- bYes, stored procedures cannot accept string parameters
- cNo, but only because triggers fire before the dynamic SQL inside the procedure is ever compiled
- dNo, dynamic SQL built from parameters inside the procedure is still injectable✓
Explanation:Moving code into a stored procedure changes where the SQL is assembled, not how. If the procedure itself concatenates an untrusted parameter into a string that is then executed dynamically (e.g. EXEC(@sql)), the same injection risk exists as in application-level string building. Safety comes from using parameter binding inside the procedure too, not from the mere fact that it lives in the database.
As Injection Input ValidationDifficulty 1
A code review flags a query where a numeric product ID is concatenated without quotes: "SELECT * FROM products WHERE id = " + productId. Why can this still be SQL injection, even though there are no surrounding quotes to break out of?
- aIt cannot be injected because numeric fields never accept text
- bNo quotes needed in numeric context,
1 OR 1=1 injects fine as-is✓ - cIt is only exploitable if the column is a floating-point type
- dNumeric concatenation is always converted to a stored procedure call by the database driver automatically
Explanation:Quote-escaping matters for string contexts, but a numeric context needs no quotes at all — the raw input is inserted directly as SQL. An attacker submitting 1 OR 1=1 (or worse, a subquery/UNION) changes the query's logic without ever needing a quote character, so unquoted numeric concatenation is just as unsafe as quoted string concatenation.
As Injection Input ValidationDifficulty 2
A login form's backend builds "SELECT * FROM users WHERE username = '" + user + "' AND password = '" + pass + "'". An attacker submits admin' -- as the username, leaving the password field empty. What effect does the -- sequence have in most SQL dialects?
- aIt starts a comment, so the rest of the line including the password check is ignored✓
- bIt escapes the following characters, making them literal text
- cIt forces the query to return zero rows regardless of the username
- dIt is invalid syntax in every SQL dialect, so the database rejects the entire query outright
Explanation:-- begins an inline comment in most SQL dialects, so everything after it on that line — including AND password = '...' — is discarded by the parser. The resulting query effectively becomes WHERE username = 'admin', authenticating as admin without any valid password, which is why unescaped input reaching query text is dangerous beyond just breaking out of quotes.
As Injection Input ValidationDifficulty 2
A developer HTML-encodes user input before inserting it into a page (< becomes <, etc.) and inserts the encoded string into a <script> block as var name = "{{ encoded_name }}";. Why can this still be exploitable even though HTML encoding was applied?
- aHTML encoding is reversed automatically by the browser's JavaScript engine before the script block runs
- bThe
<script> tag ignores all encoding rules by design - cIt cannot be exploited; HTML encoding covers every rendering context
- dJavaScript strings have their own dangerous characters, like
" and \, unaffected by HTML encoding✓
Explanation:Output encoding must match the context where data lands. HTML encoding neutralizes <, >, &, and quotes for HTML markup, but inside a JavaScript string literal the dangerous characters are things like unescaped ", ', \, and line terminators, which HTML entity encoding does not touch. An attacker supplying "; alert(1); // can close the string and inject script that HTML encoding never addressed.