SQL injection (SQLi) is an attack class where untrusted input — a form field, URL parameter, or HTTP header — is concatenated into a SQL statement, letting the attacker change the query's structure. Successful exploitation can read arbitrary tables, modify or delete data, escalate privileges, or in some configurations execute operating system commands. It has been on the OWASP Top Ten for over two decades.
Why it matters
A single SQLi flaw can leak an entire user database, including hashed credentials, session tokens, and personal data covered by GDPR. Cleanup costs include forced password resets, breach disclosure, regulatory fines, and lasting trust damage. Unlike many vulnerabilities, SQLi is fully preventable with disciplined coding practices — the impact-to-effort ratio of fixing it is enormous.
How to fix
- Use parameterised queries or prepared statements in every database call; never build SQL by string concatenation.
- Prefer a vetted ORM or query builder so application code never sees raw SQL fragments mixed with user input.
- Apply least privilege: the application's database user should not be able to drop tables or read unrelated schemas.
- Validate and normalise input at the boundary, but treat validation as defence in depth, not the primary control.
- Layer broader web defences — strict CSP, anti-CSRF tokens, and HSTS — so a single input bug does not cascade.
- Run automated SAST and DAST scans in CI, and review query logs for unusual patterns.