What is SQL injection in one sentence?

SQL injection is a vulnerability where untrusted input is treated as part of a database query, letting an attacker change what that query does.

What is the single best defense against SQL injection?

Parameterized queries (prepared statements). They send the query structure and the user data to the database separately, so input can never change the meaning of the statement.

Do ORMs prevent SQL injection?

Mostly. ORMs parameterize by default, but raw-SQL escape hatches, dynamic column or table names, and string-built LIKE clauses can reintroduce the flaw if you are not careful.

What is blind SQL injection?

A variant where the application does not return query results directly, so the attacker infers data one bit at a time from true/false responses or time delays in the page.

Is SQL injection still common in 2026?

Yes. Injection has appeared in the OWASP Top 10 for over two decades and still surfaces regularly in legacy code, hand-rolled query builders, and reporting features.

Glossary · Security

What is SQL Injection?

SQL injection is a vulnerability that occurs when an application builds a database query by gluing untrusted user input directly into the query text. Because the database cannot tell the difference between the developer's intended command and the attacker's smuggled-in fragment, a single unescaped field can let an outsider read every row in a table, bypass a login, or in the worst cases delete the database entirely.

The root cause

Almost every web application talks to a database in SQL, a language where keywords, table names, and the actual data values all live in the same string. The vulnerability appears the moment a developer constructs that string by concatenation — taking a value typed into a search box or a login form and pasting it into the middle of a query. The database faithfully executes whatever it receives, so if an attacker types something that looks like SQL instead of an ordinary value, the database runs it as code. The whole class of bug comes down to mixing instructions and data in the same channel.

A long, expensive history

SQL injection was first described publicly in the late 1990s and has never left the OWASP Top 10. It sat at the very top of that list for years and remains folded into the broader OWASP Top 10 injection category today. It has been behind some of the largest breaches on record — retail point-of-sale systems, payment processors, and government databases — precisely because a query flaw in one neglected endpoint can expose an entire data store. The persistence of such an old, well-understood bug is a reminder that secure coding is a discipline, not a one-time fix.

What an attacker can do

The impact ranges from embarrassing to catastrophic. Read access lets an attacker dump customer records, password hashes, and internal data. Authentication bypass lets them log in as any user, sometimes as an administrator, without a password. Write access lets them alter prices, grant themselves privileges, or plant malicious content. In environments where the database account is over-permissioned, injection can escalate into command execution on the server itself — turning a web bug into a full host compromise. Severity tracks directly with how much the application and its database account are allowed to do.

How to prevent it

The fix is decades old and reliable: use parameterized queries, also called prepared statements, so the query structure is sent to the database separately from the user-supplied values. With parameters, input is always treated as data and can never change the shape of the statement. A well-configured ORM does this by default. Layer on least-privilege database accounts, strict input validation, and a web application firewall as defense in depth — but the firewall is a backstop, not a substitute for parameterization in the code.

At QUANT LAB

We attack SQL injection from both sides. In our web application penetration tests we hunt for injectable parameters across search fields, filters, reporting tools, and the JSON bodies of internal APIs — the places teams forget when they assume their ORM has them covered. On the build side, the applications we ship use parameterized queries everywhere by default, scoped database roles, and code review that flags any hand-built SQL string. Catching an injection flaw before launch is cheap; catching it after a CVE is published is not.

A note on close cousins

SQL injection is the most famous member of a larger family of injection flaws. The same mix-code-with-data mistake produces command injection, LDAP injection, NoSQL injection, and template injection. The defensive instinct is identical everywhere: never let untrusted input cross into an interpreter as code. If you internalize that one principle for SQL, you have most of what you need to reason about the rest of the category — and about related client-side flaws like cross-site scripting.

Long-form deep-dives that use this term

All posts

Related terms

Worried your app is injectable?

We test web applications the way a real attacker would and ship code that closes injection by design. Book a 30-minute call.

Web app pentest