What is SQL injection?

SQL injection is a web vulnerability where an attacker inserts malicious SQL fragments into input that an application concatenates into a database query, changing the query's meaning. This can let the attacker read, modify, or delete data they should not access, bypass authentication, or in some cases run commands on the database server. It is one of the oldest and most damaging injection flaws.

How does SQL injection work?

SQL injection works when untrusted input is placed directly into a SQL statement, so characters like quotation marks or a tautology such as OR one equals one break out of the intended data context and become executable query logic. The database cannot distinguish attacker-supplied structure from the developer's, so it runs the combined statement. Results may return in the response, appear through error messages, or be inferred from timing and boolean behavior.

How do you prevent SQL injection?

The primary defense is using parameterized queries, also called prepared statements, which send the query structure and user data separately so input can never change the query's meaning. Reinforce this with input validation, least-privilege database accounts, and ORMs or stored procedures that parameterize by default. Avoid building queries by string concatenation, and validate any dynamic identifiers that cannot be parameterized.

What is the difference between SQL injection and cross-site scripting?

SQL injection targets the database by injecting malicious SQL into server-side queries, while cross-site scripting targets other users by injecting JavaScript that runs in their browsers. SQL injection typically exposes or corrupts stored data, whereas XSS hijacks sessions or acts on the victim's behalf in the browser. Both stem from mixing untrusted input with code or query structure, but they affect different layers and need different defenses.

What is blind SQL injection?

Blind SQL injection is a variant where the application does not return query results or database errors directly, so the attacker cannot see output. Instead they infer data by asking true-or-false questions and observing differences in the response, or by injecting time delays and measuring how long the server takes to reply. It is slower to exploit but just as capable of extracting data, and parameterized queries prevent it the same way.

Why is SQL injection so dangerous?

SQL injection is dangerous because a single flaw can expose or destroy an entire database, including credentials and sensitive personal data, and may allow authentication bypass or movement into the underlying server. Because databases often hold an organization's most valuable information, successful attacks can be severe and hard to contain. Its impact and prevalence keep it among the top web application risks.

◇ Web Security

SQL Injection Explained and How to Prevent It

SQL injection is a vulnerability that lets an attacker interfere with the queries an application sends to its database. By supplying crafted input that a program concatenates directly into SQL, an attacker can read data they should not see, modify or delete records, bypass authentication, and in some configurations run commands on the database server. It consistently ranks among the most damaging web application flaws because databases hold the data attackers want most.

How SQL Injection Works

Applications build SQL queries to fetch and store data. When developer-written SQL is combined with untrusted input using string concatenation, an attacker can break out of the intended data context and change the query's meaning. Consider a login query built by joining strings:

# Vulnerable: user input is concatenated into the SQL text
query = "SELECT * FROM users WHERE email = '" + email + "'"

If the attacker submits ' OR '1'='1 as the email, the resulting query always matches, potentially returning every row. The database faithfully executes whatever query it receives; it has no way to know the input was meant to be plain data rather than SQL syntax.

What Attackers Can Achieve

The impact of SQL injection depends on the database and the privileges of the account in use, but it is frequently severe. Attackers use it to dump entire tables of credentials and personal data, bypass login checks by forcing a query to return a valid row, and alter or destroy records. With a powerful database account or certain database features enabled, injection can escalate to reading files or executing operating-system commands on the database host, turning a single input flaw into full server compromise. Understanding this range of impact explains why the defenses below are non-negotiable.

Common Types of SQL Injection

In-Band Injection

In-band attacks use the same channel to inject and read results. Error-based injection extracts information from database error messages, while union-based injection appends a UNION SELECT to pull data from other tables into the visible response.

When the application returns no data or errors, attackers use blind techniques. Boolean-based injection infers information one bit at a time by observing whether a page changes when a condition is true or false. Time-based injection asks the database to pause when a condition holds, revealing data through response timing.

Out-of-Band Injection

When results cannot be read directly, an attacker may induce the database to make a network request, such as a DNS lookup, that carries data to a server they control. This relies on specific database features being enabled.

How to Prevent SQL Injection

The good news is that SQL injection is highly preventable with disciplined coding practices.

Use Parameterized Queries

The single most effective defense is to use parameterized queries, also called prepared statements. The query structure is defined separately from the data, so input can never change the query's meaning:

# Safe: the driver sends structure and data separately
cur.execute("SELECT * FROM users WHERE email = %s", (email,))

The placeholder is bound to the value by the database driver, which treats it strictly as data. Nearly every language and database offers this mechanism, and it should be the default choice.

Prefer Well-Configured ORMs

Object-relational mappers and query builders generate parameterized queries by design. They remove most opportunities for manual string concatenation, though you must still use parameters when writing any raw SQL through them.

Apply Least Privilege

The account the application uses to reach the database should have only the permissions it needs. If an application never drops tables, its database user should not be able to. This limits the damage if an injection point is found.

Validate and Constrain Input

Validate input against expected types and formats as defense in depth. This matters most for query parts that cannot be parameterized, such as table or column names, which should be checked against an allowlist of known-safe values rather than taken from user input.

Additional Layers

Escaping input correctly for the specific database is a fallback when parameterization is impossible, but it is error-prone and should not be the primary control. A web application firewall can block obvious payloads, yet it must never replace secure code. SQL injection sits in the broader injection category described in the OWASP Top 10, and like cross-site scripting it fundamentally stems from mixing code and untrusted data.

Detecting and Testing Safely

In authorized assessments, testers probe inputs with characters that have special meaning in SQL and observe how the application responds. Automated scanners and static analysis can flag risky patterns such as string-built queries. The most reliable long-term signal is a codebase where every query uses parameters, making injection structurally difficult.

Key Takeaways

SQL injection manipulates database queries by injecting SQL through untrusted input that is concatenated into query text.
Attack styles include in-band union and error-based, blind boolean and time-based, and out-of-band techniques.
Parameterized queries and prepared statements are the primary and most effective defense.
Least-privilege database accounts, input validation, and allowlists for identifiers add defense in depth.
Firewalls and manual escaping are fallbacks only; secure, parameterized code is the real fix.

sql-injectiondatabase-securityweb-securityinput-validationappsec