SQL injection is a security vulnerability in which attackers inject malicious SQL statements; which practice mitigates it?

• A. NoSQL databases are immune to SQL injection.
• B. SQL injection can only occur in prepared statements.
• C. Parameterized queries separate code from data, preventing execution of injected SQL.
• D. Parameterized queries embed user input directly into SQL text.

Answer: (C)

The key defense is using parameterized queries (prepared statements) that separate code from data. When you define a SQL statement with placeholders and then bind user-provided values separately, the database treats those values strictly as data, not as part of the SQL command. This means even if a user inputs something that looks like SQL, it cannot be executed as code, because it’s never concatenated into the command string.

For example, building a query by string concatenation can be dangerous: if the user enters something like ' OR 1=1; --, the whole input could become part of the SQL and alter the meaning of the query. With a parameterized approach, you’d write a statement like SELECT * FROM users WHERE username = ? and then bind the input as a value. The database sees the placeholder as a single data value to compare against, so the injected text is just data, not executable SQL.

The other statements aren’t accurate. NoSQL databases aren’t inherently immune to injection-like issues, and injection can occur in contexts beyond prepared statements, so relying on that assumption is risky. The idea that SQL injection can occur only when using prepared statements is incorrect—the vulnerability arises when you fail to separate code from data. And parameterized queries do not embed user input directly into the SQL string; they keep the code and data separate, which is why they effectively prevent injection.