What Is SQL Injection (SQLi)? How It Works and How to Prevent It
SQL injection (SQLi) is one of the oldest and most damaging web vulnerabilities — a single unguarded input field can expose an entire database. Here is how SQLi attacks work, the main types, their real-world impact, and how to prevent them.
SQL injection is one of the oldest tricks in the attacker's playbook — and more than two decades after it was first documented, it is still one of the most common ways data gets stolen. In 2026 it remains on the OWASP Top 10, the security industry's reference list of the most critical web application risks, and it is still a recurring root cause behind large customer-data breaches. The reason it endures is uncomfortable: SQL injection (SQLi) exploits something every data-driven website does — talk to a database — and a single careless input field can expose everything behind it.
SQL injection (SQLi) is a web security vulnerability that lets an attacker interfere with the queries an application sends to its database. By submitting input that the application mistakenly treats as SQL code rather than data, an attacker can read, modify, or delete information they were never meant to touch — often an organization's entire customer database.
This guide explains SQL injection in full: what it is, how the attack works, the main types, what attackers can achieve with it, real-world impact, and — most importantly — how to prevent it. It is part of our broader guide to the types of cyberattacks, and it treats SQLi as a defensive topic: the goal here is to understand the flaw well enough to close it, not to weaponize it.
How a SQL Injection Attack Works
To understand SQL injection, picture how a normal web application behaves. When a user logs in or searches a site, the application takes what they typed and places it into a SQL query — Structured Query Language, the language applications use to read and write data — which it then sends to the database. If the application treats that input strictly as data, everything works as intended.
The vulnerability appears when the application instead glues the user's input directly into the text of the query. Now an attacker can submit input that is not data at all but additional SQL syntax — characters that end the intended query early and append a new condition or command. Because the database receives one continuous instruction, it cannot tell where the developer's SQL stops and the attacker's begins, so it simply executes both.
The root cause, in every case, is the same: untrusted input being treated as trusted code. That single principle explains every variant of the attack — and, as we will see, it is also the key to prevention. SQL injection is a textbook software vulnerability; when an attacker actually uses it to run their own commands, that act of turning the flaw into unauthorized access is what security professionals call an exploit.
A Safe Illustration of the Idea
A concrete example makes the mechanism clear — without needing a working payload. Imagine a login form whose behind-the-scenes query asks the database, in effect, “find the account where the username and password match what was typed.” If the application builds that question by pasting the typed text straight into the query, the input box stops being a box for data and becomes a box for instructions.
An attacker's goal, conceptually, is to add a clause the database will always consider true — an always-true condition — and to comment out or neutralize the part of the query that checks the password. The database, obediently, returns a matching account and treats the visitor as logged in. No password is ever guessed; the check is simply bypassed. We are deliberately describing this at the level of the idea rather than printing a copy-paste string, but the takeaway is the important part: the difference between a secure login and a wide-open one can be a single missing safeguard around one input field.
● HOW ONE LOGIN FIELD BECOMES A BREACH The path a SQL injection attack takes from an ordinary input box to a stolen database. |
1 · USER INPUT A visitor types into a login or search box — but the characters are chosen to be read as SQL, not as data. |
| ↓ |
2 · UNSANITIZED QUERY The app pastes that raw input straight into a SQL statement, so the typed text becomes part of the command. |
| ↓ |
3 · DATABASE OBEYS Unable to tell code from data, the database runs the attacker’s logic — the login check is forced to pass. |
| ↓ |
4 · DATA EXPOSED The query returns rows it never should — credentials, customer records, payment data — with no valid password used. |
Source: OWASP — SQL Injection. Illustrative flow; no working payload shown. |
Types of SQL Injection Attacks
Security researchers usually group SQL injection into three families, based on how the attacker gets the results back. Under those families sit the specific techniques that appear in real assessments and in OWASP's own guidance.
- In-band (classic) SQLi — the attacker uses the same channel to launch the attack and receive the results. Two common sub-techniques are error-based injection, where the database's own error messages leak data, and union-based injection, which uses the SQL UNION operator to append the results of another query to the application's normal output. This is the simplest and most direct form.
- Blind (inferential) SQLi — the application returns no data and no visible errors, so the attacker infers information indirectly. In boolean-based blind injection they watch whether a page's response changes when a true-or-false condition is injected; in time-based blind injection they measure how long the database takes to respond, reading the delay as a one-bit answer. It is slower, but just as dangerous.
- Out-of-band SQLi — the attacker makes the database send results through a separate channel, such as a DNS or HTTP request to a server they control. It is used when in-band and blind techniques are not viable, and it depends on specific database features being enabled.
What Attackers Can Do — and the Real-World Impact
A successful SQL injection attack is dangerous precisely because it strikes the database, usually where an organization's most valuable information lives. Depending on the application and the permissions of the database account it uses, an attacker may be able to:
- Read sensitive data — customer records, credentials, payment details, and other confidential information.
- Modify or delete data — altering records, corrupting data, or wiping entire tables.
- Bypass authentication — logging in as another user, including an administrator, without a valid password.
- Escalate the attack — in some configurations, using database functionality to read files or run commands on the underlying server, turning a web flaw into a full server compromise.
The historical record shows how costly this can be. SQL injection was the technique behind some of the most consequential breaches of the past fifteen years — including the 2008 Heartland Payment Systems compromise, which exposed well over 100 million payment cards, and the 2011 Sony Pictures and 2015 TalkTalk incidents, both of which leaked large volumes of customer data through injectable web applications. Attackers have also weaponized SQLi at scale against content-management and e-commerce plugins, using a single flaw to loot many sites at once. Because it so reliably leads to the mass theft of personal data, SQLi is a frequent root cause behind the incidents covered in our guide to the types of cyberattacks.
How to Prevent SQL Injection
The encouraging news is that SQL injection is highly preventable. The defenses are well established, and applied together they close the vulnerability almost entirely. They map closely to the guidance in the OWASP SQL Injection Prevention Cheat Sheet.
- Use parameterized queries. Also called prepared statements, these send the SQL command and the user input to the database separately, so input can never be reinterpreted as code. This is the single most important defense — the direct antidote to the root cause.
- Prefer safe frameworks and ORMs. Modern object-relational mapping libraries use parameterized queries by default. They are safe as long as developers do not drop down to raw, string-built queries and bypass the protection.
- Validate and sanitize input. Rejecting input that does not match the expected format (and using allow-lists where values are constrained, such as sort orders) is a valuable extra layer — though it supplements parameterization rather than replacing it.
- Apply least privilege. Give each application's database account only the permissions it genuinely needs, so a successful injection does the least possible damage. This is the same principle that limits blast radius in cloud security.
- Deploy a web application firewall. A WAF can filter many injection attempts as defense in depth — useful, but a supplement to secure code, never a substitute for it.
- Test regularly. Vulnerability scanning, code review, and penetration testing catch injectable code paths before attackers do.
SQL Injection and the OWASP Top 10
SQL injection sits inside the broader “Injection” category of the OWASP Top 10, the security industry's most widely referenced list of critical web application risks. Injection has appeared on every edition of that list since it was first published — it was ranked A03 in the 2021 edition and A05 in the 2025 edition — a testament to how common and how serious the flaw remains even as other risk classes rise around it. Tracking and remediating weaknesses like it at scale is the job of a mature vulnerability management program.
Frequently Asked Questions
What is SQL injection in simple terms?
SQL injection (SQLi) is a web vulnerability that lets an attacker interfere with the database queries an application makes. It works when a site accepts user input and treats it as SQL code rather than plain data, allowing the attacker's input to run as a command against the database.
What can a SQL injection attack do?
Depending on the application and database permissions, SQLi can let an attacker read sensitive data, modify or delete records, bypass login authentication, and in some configurations run commands on the underlying server — which is why it so often ends in a large data breach.
What is the best defense against SQL injection?
Parameterized queries (prepared statements) are the single most effective defense, because they keep user input strictly separate from SQL code. They are reinforced by safe ORMs, input validation, least-privilege database accounts, a web application firewall, and regular security testing.
Is SQL injection illegal?
Running a SQL injection attack against a system you do not own or have explicit written permission to test is illegal. The technique is studied and practiced lawfully only in authorized penetration testing and in controlled training environments built for that purpose.
