SQL injection
User input your database runs as part of the query instead of treating as data, so a typed quote can read or wreck everything.
See it
What it is
Your app builds a query by gluing strings together, so the database cannot tell where your SQL stops and the user's text starts. Type a quote and you close the string early; everything after it is read as code. The canonical payload is ' OR '1'='1 in a login box, which turns 'find the row matching this password' into 'find any row at all'. From there attackers UNION in other tables to dump them, and when the page shows no output they go blind, asking yes/no questions and reading the answer off response timing with pg_sleep or BENCHMARK.
The fix is not escaping quotes, and it is not a blocklist of the word 'DROP'. Use parameterized queries (prepared statements, bound placeholders): you send the query shape and the values on separate channels, so a value can never become syntax no matter what is in it. Every real driver and ORM supports this, and most do it by default.
Gotcha: using an ORM does not make you immune, because the escape hatches are where injection lives. Raw query fragments, string-built WHERE clauses, and dynamic ORDER BY all bypass binding. Second gotcha: you cannot parameterize identifiers. Table names, column names, and sort direction have to be checked against an allowlist you wrote, not interpolated from the request. And input that was safe on the way in can still bite later: second-order injection is stored text that gets concatenated into a query by some other job days afterwards.
Ask AI for it
Audit this codebase for SQL injection and fix it. Find every query built with string concatenation, template literals, or f-strings that include request data, and rewrite each one as a parameterized query using the driver's bound placeholders, keeping behavior identical. For the parts that cannot be parameterized (table names, column names, ORDER BY direction, LIMIT), validate the value against a hardcoded allowlist and reject anything else with a 400. Do not add quote escaping or keyword blocklists as a substitute. Then add tests that post payloads like ' OR '1'='1 and '; DROP TABLE users; -- through each affected endpoint and assert the input is stored or matched literally with no extra rows returned.