Glossary · simply explained

SQL injection

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.

Frequently asked questions about SQL injection

Why does SQL injection still exist?

Because vulnerable code is long-lived: legacy applications, plugins, acquired systems and haste keep producing concatenated queries. Attackers scan for them automatically — yesterday’s flaw is found tomorrow. Hence code hygiene plus a protective layer.

Does a WAF reliably prevent SQL injection?

It blocks known patterns very effectively and shields new CVEs via virtual patching — but a determined attacker with time can evade filters. The WAF is the important second layer; the first remains clean code with parameterised queries.

What are prepared statements?

Queries with placeholders where the database receives command and data separately: the query structure is fixed, inputs are treated as values only. Classic SQL injection is thereby excluded by construction — available in practically every language.

What is blind SQL injection?

A variant without visible error messages: the attacker asks yes-no questions via the application’s behaviour — such as response times with injected delays — and reconstructs data bit by bit. Slower, but just as effective and automatable.

How do I find SQLi flaws in my applications?

Through combination: automated scanners for breadth, penetration tests for depth, code reviews at the database access points. For systems you cannot change: put them behind the WAF, minimise rights and restrict access to the essentials.

Wondering how this looks in your own network? Talk to KAEMI: we plan, build and manage the right solution with you.