What Is SQL Injection (SQLi)? How It Works, Types & Prevention

SQL injection (SQLi) is a web security vulnerability that lets an attacker interfere with the queries an application makes to its database. By inserting — or "injecting" — malicious SQL code into an input that the application passes to its database, an attacker can read data they shouldn't, modify or delete records, bypass authentication, and sometimes take control of the underlying server. Despite being decades old, SQL injection remains one of the most common and serious vulnerabilities on the web, consistently featured in the OWASP Top 10.

In short: SQL injection happens when an application trusts user input enough to let it change the meaning of a database command. The attacker types code where the app expected data — and the database obeys.

How SQL injection works

Web applications constantly build database queries that include user-supplied values — a username, a search term, a product ID. If the application inserts that input directly into a SQL statement without properly separating code from data, an attacker can craft input that breaks out of the intended value and adds their own commands.

A classic example is an authentication bypass. Suppose a login checks the database with a query that includes the username and password from the form. An attacker enters a username like ' OR '1'='1. Because '1'='1' is always true, the query can be tricked into returning a valid user and logging the attacker in without a password. That's the essence of injection: the attacker's input changed the logic of the query itself.

Types of SQL injection

• In-band (classic) SQLi: the attacker uses the same channel to inject and receive results. This includes error-based SQLi (provoking database error messages that leak information) and union-based SQLi (using the UNION operator to pull data from other tables into the app's response).
• Blind SQLi: the application doesn't return data or errors directly, so the attacker infers information indirectly. Boolean-based blind SQLi observes how the page changes based on true/false conditions, while time-based blind SQLi measures how long the database takes to respond after being told to delay.
• Out-of-band SQLi: the attacker uses a different channel (such as making the database send a network request) to extract data when direct responses aren't available.

Why SQL injection is so dangerous

• Massive data theft. A single SQLi flaw can expose an entire database — customer records, credentials, payment data — causing a major data breach.
• Authentication bypass. Attackers can log in as other users, including administrators.
• Data manipulation and destruction. Records can be altered or deleted, undermining integrity.
• Server compromise. In some configurations, SQLi can lead to command execution on the database server and a foothold for deeper attack.

Many of history's largest breaches began with a SQL injection flaw, which is why it remains a top priority in vulnerability management.

How to prevent SQL injection

• Use parameterized queries (prepared statements). This is the single most effective defense. Parameterized queries send the SQL command and the user data separately, so input can never be interpreted as code. Treat this as the default for all database access.
• Use stored procedures and ORMs carefully. Object-relational mappers and well-written stored procedures generally use parameterization under the hood — but only if you don't reintroduce dynamic SQL with raw input.
• Validate and sanitize input. Enforce expected formats (allowlisting) as a defense-in-depth layer — though validation alone is not a substitute for parameterization.
• Apply least privilege. The application's database account should have only the permissions it needs, limiting the damage if injection occurs.
• Deploy a Web Application Firewall (WAF). A WAF can block many known SQLi patterns as an additional layer, buying time to fix the root cause.
• Test continuously. Use automated scanners and penetration testing to find injection flaws before attackers do, and patch the vulnerable code as a tracked vulnerability.

SQL injection vs cross-site scripting

SQLi is often mentioned alongside cross-site scripting (XSS) because both are injection attacks against web applications — but they target different things. SQL injection targets the application's database, executing attacker SQL on the server. XSS targets other users, executing attacker JavaScript in their browsers. Both stem from the same root cause: trusting unvalidated input. The defenses differ, but the mindset — never trust input, separate code from data — is shared.

Why SQL injection still happens

If the primary fix — parameterized queries — has been known for decades, why is SQL injection still everywhere? Several reasons keep it alive. Legacy code written before secure practices were standard still runs in production, full of dynamically built queries. Developer pressure and unawareness lead teams to concatenate input into queries because it's quick and "works" in testing. Complex applications have countless input points — search boxes, filters, APIs, headers, cookies — and a single overlooked one is enough. Third-party components and plugins introduce flaws outside a team's own code. And because automated tools constantly scan the entire internet for injectable parameters, even an obscure, rarely used endpoint can be found and exploited. The lesson is that SQL injection is not a solved problem in practice but an ongoing discipline: every input, in every component, old and new, has to be handled safely, which is why secure-by-default frameworks and continuous testing matter as much as knowing the fix.

Where threat intelligence fits

SQL injection is a favorite of both opportunistic and targeted attackers, and active campaigns scanning the internet for vulnerable parameters are constant. Threat intelligence highlights which web vulnerabilities are being actively exploited, including SQLi flaws added to catalogs of known exploited vulnerabilities — helping teams prioritize fixing the database flaws attackers are weaponizing right now.

The bottom line

SQL injection lets attackers smuggle malicious commands into an application's database queries by abusing untrusted input, enabling data theft, authentication bypass, and even server compromise. It's one of the oldest and most damaging web vulnerabilities — and one of the most preventable. Parameterized queries, least privilege, input validation, a WAF, and continuous testing close the gap. To track which web vulnerabilities attackers are actively exploiting, follow our live threat intelligence feed, aggregated from dozens of authoritative sources and linked to the National Vulnerability Database.