SQL injection

It happens when code builds a query by gluing user input into the SQL text, for example adding whatever was typed into a search box straight after WHERE name =. A visitor who types a quote character followed by SQL of their own can then change what the query means: skip a password check, read another table or delete rows. It has been well known since the late 1990s and still turns up, usually in hand-written queries.

The fix is parameterised queries (prepared statements): the SQL is sent with placeholders such as $1 or ?, and the values travel separately, so the database never mistakes data for code. ORMs and query builders such as Prisma, Drizzle, SQLAlchemy and Django's ORM do this automatically, but raw-query helpers that take a plain string, such as Prisma's $queryRawUnsafe, bring the risk back if input is pasted in.

Extra layers limit the damage: a database user with only the permissions the app needs, error pages that do not reveal SQL, and a WAF that blocks common patterns. NoSQL databases have their own form of injection when user input is passed straight into a query object.