Type ' OR 1=1 -- into a login box. A string-built query hands the attacker every row; a parameterized query treats it as harmless text. Watch the actual SQL the database receives in both cases.
A login form. Choose what the attacker types in the username box, toggle parameterized queries, and run it — watch the exact SQL the database receives.
Username input
SQL the database executes
SELECT * FROM users WHERE name = 'admin' --' AND pass = '•••'
Run admin' -- as a string-built query (password check vanishes), then flip to parameterized and run the same input — now it's just a username that doesn't exist.
What just happened
▹Injection happens when untrusted input is concatenated into a query string, so the input can change the query's STRUCTURE instead of just supplying a value. ' OR '1'='1 turns a login check into 'always true'.
▹Parameterized queries (prepared statements) send the SQL and the data separately. The database treats your input strictly as a value — quotes and dashes are just characters, never executable SQL.
▹The fix is architectural, not heroic: never build queries by string concatenation. Use parameters / a safe ORM and validate input at the API boundary. Same idea defends NoSQL, LDAP and command injection.