A penetration tester types ' OR '1'='1 into the password field of an internal web application and is logged in as the first user in the table. The application builds its login query by concatenating the form values into a SQL string. What is this attack, and how should developers fix it?

This is SQL injection. Because the application concatenates the form values into the statement text, the input ' OR '1'='1 closes the string literal and appends a condition that is always true, so the WHERE clause matches every row and the query returns the first user. The robust fix is to use parameterized statements, also called prepared statements, in which the SQL text contains placeholders and the values are bound separately; the database treats bound values strictly as data, so quote characters cannot alter the query's structure. Cross-site scripting injects script into pages rendered in a victim's browser; output encoding prevents that, but the attack here manipulates the database query, not the HTML. Client-side JavaScript validation is easily bypassed by sending the request directly or disabling scripts in the browser, so it provides no protection at the server. Account lockout counters password guessing, but this login succeeded on the first attempt without guessing anything, so lockout never triggers. Exam caveat: stored procedures help only when they do not build dynamic SQL by concatenation inside. Operational check: review the data-access code for string-built SQL and confirm the same input now fails to log in.