What is SQL Injection?

Definition

SQL injection (SQLi) is a code injection attack in which an attacker inserts malicious SQL statements into an input field that is concatenated into a database query. When the application executes the modified query, the injected SQL runs with the privileges of the database user — enabling attackers to read sensitive data, modify records, delete tables, or in some configurations execute operating system commands.

SQL injection has consistently appeared in the OWASP Top 10 for over two decades. It remains one of the most exploited web application vulnerabilities because the root cause — concatenating untrusted input into a query string — is a pattern that appears naturally when developers build data-driven applications without security training.

How SQL Injection Works

Consider a login form that checks credentials with this query:

SELECT * FROM users WHERE username = 'input_username' AND password = 'input_password'

An attacker enters the username: admin'-- and any password. The resulting query becomes:

SELECT * FROM users WHERE username = 'admin'--' AND password = 'anything'

The -- comment sequence causes the database to ignore the password check entirely. The attacker is authenticated as admin without knowing the password.

Types of SQL Injection

In-band SQLi

The attacker receives results directly in the application response. Classic and error-based SQLi fall into this category. It is the most common and easiest to exploit.

Blind SQLi

The application does not return query results in its response, but the attacker can infer data by asking true/false questions (Boolean-based) or causing deliberate delays (time-based). Slower to exploit but equally dangerous.

Out-of-band SQLi

The attacker receives data through a separate channel — DNS lookups, HTTP requests to an external server. Requires specific database server capabilities but can bypass many security controls.

Impact

A successful SQL injection attack can result in:

• Complete extraction of the database including user credentials, PII, and financial data
• Authentication bypass without knowing any password
• Data modification or deletion
• Database administrator privilege escalation
• In some configurations: operating system command execution via xp_cmdshell or INTO OUTFILE

Prevention

SQL injection is well-understood and fully preventable:

Parameterized queries / prepared statements

The single most effective defense. Instead of concatenating user input into the query string, the query structure is defined first and values are passed separately. The database driver handles escaping — the input can never alter query structure.

Stored procedures

Pre-compiled SQL routines that separate logic from data. Effective when implemented correctly, but stored procedures can themselves be vulnerable if they use dynamic SQL internally.

Input validation and allowlisting

Reject input that does not match an expected format. For numeric IDs, reject anything that is not a number. For usernames, reject characters that have no business being in a username. This is defense in depth, not a primary control.

Principle of least privilege

The database user the application connects as should have only the permissions it needs. A read-only API should connect with a read-only database user. This limits the blast radius of a successful injection.

SQL Injection and Autonomous Code Governance

SQL injection is one of the highest-priority targets for autonomous code governance because the fix pattern is well-defined: replace string concatenation with parameterized queries. Hydra detects SQL injection patterns through taint analysis — tracing data flow from user-controlled sources (request parameters, headers, cookies) to query construction — and generates parameterized query replacements that match the codebase's existing database access patterns. The fix is verified with tests before delivery.