During a code audit, a reviewer finds a login function that builds a query by concatenating the username and password typed by the user directly into a SQL string. Which remediation should the reviewer require?
Select an answer to reveal the explanation.
Short Explanation
Concatenating user input into SQL is like letting a stranger finish your sentence in front of the judge. With parameterized statements, the database treats whatever they type as data, never as code. Escaping quotes is the classic trap; you'll always be one clever trick behind an attacker.
Full Explanation
Building SQL by concatenating user input allows SQL injection: crafted input can close the intended literal and append its own clauses, for example to bypass the password check or extract other tables. Parameterized statements, also called prepared statements with bound parameters, send the query text and the input values to the database separately. The engine parses the statement structure first and then treats each bound value strictly as data, so input can never change the query's logic. Manually escaping quotes is fragile; it depends on character sets, data types and contexts that differ across engines, and missed cases remain exploitable. Client-side validation runs in the attacker's browser and can be bypassed entirely by sending requests directly to the server, so it provides no protection for the database. TLS encrypts traffic in transit but does nothing to stop a malicious value from being embedded into the query on the server. Exam caveat: parameterization should be combined with least-privilege database accounts and server-side input validation, and stored procedures that themselves build dynamic SQL by concatenation remain vulnerable. Operational check: search the codebase for string-built queries, convert them to bound parameters, and retest the login with injection payloads to confirm they are treated as literal values.