SQL Injection

SQL Injection has sat near the top of the OWASP Top 10 for over twenty years. The reason it survives is depressing: developers keep building strings to talk to databases, and string-building plus untrusted input is the recipe. The win condition for the attacker is rarely subtle — they pull every row from your users table, dump password hashes, or write themselves an admin account.

SQL injection appears when request input can change the structure or behavior of a database query. The result can be data exposure, authentication bypass, or unintended database changes.

Full read access to every row your application's database user can see — and that user is usually privileged. Often write access too: changing prices, granting admin roles, planting persistent backdoors. In the worst case the attacker chains SQLi into RCE via stacked queries, file writes (`SELECT … INTO OUTFILE`), or PostgreSQL's `COPY` extension.

Use parameterized queries (also called prepared statements) absolutely everywhere. Modern ORMs and query builders do this by default — the bugs creep in when developers reach for raw SQL with template literals. The principle: the SQL string and the data must travel through different channels so the database never re-parses user input as code. As a second layer, give your application's DB user the minimum privileges it needs — read-only roles for read-heavy services, no DDL grants on app users, separate roles for admin operations. As a third layer, use a Web Application Firewall to drop the obvious payloads. None of these alone is enough; together they make exploitation prohibitively expensive.