SQL injection

What it means

SQL injection happens when input from outside ends up as part of a database query instead of as data inside it. The database cannot tell the difference, so it runs what you handed it.

From there an attacker reads tables you never meant to show, or quietly changes records. In some setups they reach the server the database runs on, which is remote code execution.

Why it matters

It sits behind a great many of the breaches you have read about, and it is the class most likely to expose everything at once. One vulnerable parameter can be enough to take a whole customer table.

It is also decades old and completely understood, which makes it an expensive thing for a buyer to find in your application. No incident report carries a sympathetic explanation for it. The damage rarely stops at one table either. Once an attacker can rewrite a query, they usually reach everything that database user can touch.

How it shows up

It lives wherever code assembles a query by joining strings: a search box, a sort order, a filter in a report, an id in a URL. Modern frameworks make the safe version the default, so the flaw usually turns up in the one hand written query somebody added under pressure.

Parameterised queries fix it. You tell the database the structure first and the values separately, so input can never change the shape of the query. The database account matters as well. An application connecting as an administrator turns a read into a rewrite, and narrowing those permissions limits what a mistake becomes. Test the paths nobody demonstrates, too. Export routines, admin filters and report builders all reach the database, and none of them appear in a product demo.