SQL injection is the oldest entry on the list and still among the most damaging, because a single unescaped value can hand over the whole database. It happens whenever user input becomes part of the SQL text instead of staying a value. Subsection 4.16.5 dissects it at length with a live demonstration; the reminder here is a login lookup with a WHERE email = '$email' clause built by concatenation, and the same clause using a ? placeholder. Passed the classic bypass payload x' OR '1'='1 with curl 3,008 , the concatenated branch returned 8 row(s): Ana Souza, Ben Carter, Chen Wei ... and the prepared branch 0 row(s):. The payload closes the quote and adds OR '1'='1, true for every row, so concatenation returned all eight customers; a login form written this way lets anyone in. The prepared statement sent the SQL and value on separate paths, so the database searched for a customer whose email is literally x' OR '1'='1 and found none. Bind every value on every query (Subsections 4.16.5-4.16.8). The only inputs a placeholder cannot carry are table and column names and keywords, the next subsection.
MENU
SQL Injection
SQL Injection and Why Prepared Statements Stop It