What Is SQL Injection?

SQL injection occurs when user-supplied input is incorporated into a database query in a way that lets the input alter the query's structure. The attacker's text stops being data and becomes instruction.

It has been well understood for decades and it persists, because the mistake is easy to make in any code that builds a query by joining strings together.

What it yields

Reading data the application never intended to expose, including other users' records and entire tables. Modifying or deleting data. Bypassing authentication by altering the logic of a login query.

In some configurations, executing commands on the database host, reading files, or reaching other systems the database server can contact — which turns an application flaw into infrastructure access.

The fix is parameterisation, not filtering

Parameterised queries send the query structure and the values separately, so input cannot change the structure regardless of what it contains. That is a complete fix rather than a mitigation.

Input filtering and escaping are incomplete by nature: they depend on anticipating every encoding and syntax that could be meaningful, and attackers are better at finding exceptions than developers are at enumerating them.

Why it still appears

Legacy code written before frameworks made the safe path the default. Dynamic query construction for features like flexible search or sorting, where the structure genuinely varies. Stored procedures that build and execute strings internally.

And copied examples, which propagate the unsafe pattern. Frameworks have made this rare in new code and it is very much present in code that is still running.

Limiting the consequence

The database account an application uses should have only the rights that application needs — not administrative rights, not access to unrelated tables. A successful injection then reaches considerably less.

This is widely ignored, and applications routinely connect with highly privileged accounts because it was simpler during development. It is one of the cheaper hardening steps available and it requires no code change.

Finding it

Static analysis identifies string-built queries reliably and is the efficient first pass. Dynamic testing and manual testing find what static analysis misses, particularly in stored procedures and dynamic query builders.

A web application firewall blocks common attempts and is a stopgap, not a remedy — it buys time for a fix rather than replacing one.

The same flaw in other query languages

The pattern is not specific to relational databases. Document database queries, directory lookups, search engine queries, template engines, operating system commands and object query languages all have equivalent injection forms, and all arise from the same mistake of building a statement by joining strings.

Command injection into a shell is the most consequential relative, because it yields code execution directly. The principle is identical: pass values as parameters to a structured interface rather than assembling text a parser will interpret.

Where to start

Search your codebase for queries built by string concatenation. Each one is a candidate, and the search takes minutes.

See database security. GuardsArm delivers application penetration testing.