SQL injection (SQLi) is the smuggling of database commands through an application’s inputs: if user input is built into SQL queries unchecked, an attacker can rewrite the query — reading, changing or deleting data, or bypassing authentication.
Despite decades of awareness, SQLi remains among the OWASP top risks: legacy applications, acquired systems and quick extensions keep supplying vulnerable code — and automated scanners find it reliably.
How SQL injection works
The classic example: a login assembles its query from user input. Entering a crafted expression makes the password check true — the attacker is logged in. Advanced variants read foreign tables via UNION or work blind through time delays when the application reveals no errors.
The clean solution lies in the code: parameterised queries (prepared statements) strictly separate command and data — input can then no longer change the query. A WAF adds a second layer: it blocks known injection patterns and shields freshly reported flaws until the code is patched.
Defence in depth
- Prepared statements everywhere — no concatenated SQL strings.
- Minimal rights for the application’s database accounts: only necessary tables and operations.
- WAF with managed rules as a protective layer in front of legacy and third-party code.
- Keep error messages sparse: no SQL details to the client.