What Is SQL Injection (SQLi)?

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. It is consistently named in lists of the most critical web application security risks, and it remains behind a steady stream of real-world breaches.

What makes SQL injection so persistent is that it exploits something every data-driven website does: talk to a database. When an application handles user input carelessly, an attacker can slip database commands into that input and make the application run them. The result can be the quiet theft of an 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, and — most importantly — how to prevent it. It is part of our broader guide to the types of cyberattacks.

What Is SQL Injection?

SQL injection, often shortened to SQLi, is a web security vulnerability that allows an attacker to interfere with the queries an application sends to its database. SQL — Structured Query Language — is the language applications use to read and write data, and a SQL injection attack tricks the application into running SQL the attacker controls.

The vulnerability exists wherever an application builds a database query out of user input without properly separating the input from the command. When that separation is missing, data the user types can be interpreted as instructions — and the database, unable to tell the difference, simply obeys.

How Does a SQL Injection Attack Work?

To understand the attack, picture how a normal web application works. When a user logs in or searches a site, the application takes what they typed and inserts it into a SQL query that it sends to the database. If the application treats that input purely as data, everything is fine.

The problem arises when the application instead glues the user's input directly into the text of the query. An attacker can then type input that is not data at all, but additional SQL syntax — for example, characters that close the intended query early and append a new condition or command. Because the database receives one continuous instruction, it executes the attacker's added SQL alongside the application's. A classic result is an attacker making a login check always evaluate as true, bypassing the password entirely.

The root cause, in every case, is the same: untrusted input being treated as trusted code. That single principle is also the key to prevention.

Types of SQL Injection Attacks

SQL injection is usually grouped into three categories based on how the attacker retrieves the results.

• In-band (classic) SQLi — the attacker uses the same channel to launch the attack and receive the results, reading data straight from the application's responses or error messages. It is the simplest and most direct form.
• Blind (inferential) SQLi — the application does not return data or visible errors, so the attacker infers information indirectly, for example by observing whether a page behaves differently or how long it takes to respond when a true-or-false condition is injected. 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 network request to a server they control. It is used when in-band and blind techniques are not viable.

What Can Attackers Do With SQL Injection?

A successful SQL injection attack can be devastating because it strikes the database — usually where an organization's most valuable information lives. Depending on the application and the database account's permissions, 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 tables entirely.
• 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 execute commands on the underlying server.

Because SQL injection so often leads to the mass theft of personal data, it is a frequent root cause behind the incidents covered in our guide to what a data breach is.

How to Prevent SQL Injection

The encouraging news is that SQL injection is highly preventable. The defenses are well established and, applied together, close the vulnerability almost entirely.

• Use parameterized queries. Also called prepared statements, these keep the SQL command and the user input strictly separate, so input can never be interpreted as code. This is the single most important defense.
• Validate and sanitize input. Reject input that does not match the expected format as an additional layer of protection.
• Apply least privilege. Give each application's database account only the permissions it genuinely needs, so a successful injection causes the least possible damage.
• Use safe frameworks and ORMs. Modern object-relational mapping libraries use parameterized queries by default — provided developers do not bypass them with raw queries.
• Deploy a web application firewall. A WAF can filter many injection attempts as defense in depth, though it is a supplement to secure code, not a replacement.
• Test regularly. Vulnerability scanning and penetration testing catch injection flaws before attackers do.

SQL Injection and the OWASP Top 10

SQL injection falls under the "Injection" category of the OWASP Top 10, the security industry's widely referenced list of the most critical web application risks. Injection has appeared on every edition of that list since it was first published — a testament to how common and how serious the flaw remains. SQL injection is also a clear example of a software vulnerability in the broader sense; our guide to vulnerability management covers how organizations find and fix weaknesses like it at scale.

Conclusion

SQL injection endures not because it is sophisticated, but because it is easy to introduce and easy to overlook. Any place an application accepts input and talks to a database is a potential entry point — and a single missed one can expose an entire database.

Yet for all its danger, SQL injection is a solved problem in principle. Parameterized queries, least-privilege database accounts, safe frameworks, and regular testing will stop it. The challenge is simply applying those practices consistently, everywhere user input meets a database — and that consistency is what separates a secure application from the next breach headline.

Frequently Asked Questions (FAQ)

What is SQL injection?

SQL injection (SQLi) is a web vulnerability that lets an attacker interfere with the database queries an application makes, by submitting input that the application mistakenly treats as SQL code rather than data.

What can a SQL injection attack do?

Depending on the application and database permissions, SQL injection can let an attacker read sensitive data, modify or delete records, bypass login authentication, and in some cases run commands on the underlying server.

What are the types of SQL injection?

The three main types are in-band (classic) SQLi, where results come back through the same channel; blind (inferential) SQLi, where the attacker infers data indirectly; and out-of-band SQLi, where results are sent through a separate channel.

How do you prevent SQL injection?

The most effective defense is using parameterized queries (prepared statements), which keep user input separate from SQL code. This is reinforced by input validation, least-privilege database accounts, safe frameworks, web application firewalls, and regular security testing.

Why is SQL injection still so common?

SQL injection remains common because it is easy to introduce whenever a developer builds a query from user input without proper safeguards, and because a single overlooked input field anywhere in an application can expose the whole database.

Is SQL injection illegal?

Performing a SQL injection attack against a system you do not own or have explicit permission to test is illegal. The technique is studied and practiced legally only in authorized penetration testing and controlled training environments.