Artemiy Malyshau· Co-founder & CTO7 min readWhen your login form concatenates username input directly into a SQL query string, you’re trusting that input to be data instead of executable code. SQL injection breaks that trust by crafting input that escapes the data context and injects malicious commands, letting attackers bypass authentication, extract sensitive records, or manipulate your database structure. Parameterized queries eliminate the vulnerability by separating SQL syntax from user values at the protocol level, so the database treats input as literal strings regardless of special characters or SQL keywords. We’ll cover how different injection techniques work, why prepared statements are the only reliable defense, and what keeps this decades-old vulnerability alive in modern applications.
TLDR:
SQL injection is a code injection attack where an attacker inserts malicious SQL code into an application’s database query. The attack exploits how applications construct database queries from user input.
Databases use Structured Query Language (SQL) to read, write, and manage data. When your application concatenates user input directly into an SQL query string, you’re trusting that input to be data, not code. Attackers break this by crafting input that escapes the data context and injects their own SQL commands.
Consider a simple login form building a query like: SELECT * FROM users WHERE username = ‘user_input’ AND password = ‘user_password’. Entering admin’ -- as the username changes the query to: SELECT * FROM users WHERE username = ‘admin’ --’ AND password = ''. The -- comments out everything after it, bypassing password verification.
The query executes without syntax errors. The problem is the query now does something different than intended, controlled by the attacker instead of your application logic.
SQL injection attacks fall into three main categories based on how attackers extract data and communicate with the database.
In-band attacks use the same channel to launch the attack and retrieve results. Union-based injection combines results from multiple queries using the UNION SQL operator, appending a SELECT statement to extract data from different tables. Error-based injection triggers database errors that reveal information about the database structure through error messages displayed in the application.
Inferential (blind) attacks don’t return data directly in application responses. Boolean-based blind injection sends queries that return different responses based on whether conditions are true or false, inferring data one bit at a time. Time-based blind injection uses database sleep functions to create delays where response time reveals whether conditions are true.
Out-of-band injection exfiltrates data through different channels like DNS or HTTP requests when direct response channels are unavailable. Second-order injection stores malicious input in the database that executes later when the application retrieves and uses that data in a different query without proper sanitization.
| Attack Type | How It Works | Data Extraction Method | Detection Indicators |
|---|---|---|---|
| In-Band (Union-Based) | Appends UNION SELECT statements to combine results from multiple queries, extracting data from different tables in the same response | Direct retrieval through application responses by merging attacker-controlled queries with legitimate results | Unusual UNION keywords in logs, extended query response sizes, error messages revealing table structures |
| In-Band (Error-Based) | Triggers database errors that expose schema information, table names, and column details through verbose error messages |
SQL injection continues to cause serious damage across organizations of all sizes. Web application attacks, including SQL injection, accounted for 26% of all data breaches in 2024. Among web application attacks alone, SQL injection represents 65.1% of all attack vectors.
Successful attacks expose customer databases containing personal information, payment card data, and authentication credentials. Attackers can modify or delete data, execute administrative operations, and sometimes issue commands to the underlying operating system. Financial impact compounds through incident response costs, forensic investigation, legal fees, and regulatory penalties that add millions to breach totals.
SQL injection fell to fifth in the 2025 OWASP Top 10, down from third in prior editions and first in 2017. The decline reflects systematic defenses that work: prepared statements eliminate the root cause, frameworks default to safe patterns, and automated scanners reliably detect malicious input signatures.
Broken access control claimed the top spot because authorization logic resists the same solutions. Permission checks and conditionals vary by business requirements, making them semantic problems instead of syntactic ones that pattern-matching can solve.
Parameterized queries and prepared statements separate SQL code from data by sending query structure and user input as distinct elements to the database server. When you write SELECT * FROM users WHERE username = ?, the database parses the query structure first, then binds user input to the parameter marker. The input never becomes executable code. Even if an attacker submits admin’ --, the database treats it as a literal string value, not SQL syntax.
Input validation and escaping are secondary controls. Validation catches malformed input but can’t reliably distinguish malicious SQL from legitimate special characters.
Prepared statements separate query structure from user input through a two-step process. The database compiles the SQL template first, then binds parameters as typed data values instead of executable code.
Java (JDBC):
<code class="language-java">PreparedStatement stmt = conn.prepareStatement(
"SELECT * FROM users WHERE username = ? AND password = ?"
);
stmt.setString(1, username);
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();
</code>Python (psycopg2):
<code class="language-python">cursor.execute(
"SELECT * FROM users WHERE username = %s AND password = %s",
(username, password)
)
</code>PHP (PDO):
<code class="language-php">$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->execute([$username, $password]);
</code>C# (ADO.NET):
<code class="language-csharp">SqlCommand cmd = new SqlCommand(
"SELECT * FROM users WHERE username = @username AND password = @password", conn
);
cmd.Parameters.AddWithValue("@username", username);
cmd.Parameters.AddWithValue("@password", password);
</code>
Artemiy Malyshau
Co-founder & CTO
Artemiy served in an elite unit of the Austrian Cyber Forces, defending national infrastructure He was then the first employee at a government-backed cybersecurity research group, where he led security projects for Interpol and national governments. At Gecko he builds the platform trusted to sit inside Fortune 500 codebases, and holds it to the standard those governments taught him.
The latest news, technologies, and resources from our team.
How Cal.com consolidated noisy security tooling into one continuous, context-aware pull request security program with Gecko.
Gecko Security
Authorization bypass in n8n’s dynamic-credentials OAuth endpoints allows any authenticated user to operate on another user’s OAuth credential by supplying its ID, enabling unauthorized OAuth rebinding and revocation.
Artemiy Malyshau
An IDOR vulnerability in n8n’s public variables API allows authenticated users to read project variables outside their authorized scope, exposing secrets across project boundaries.
Artemiy Malyshau
Learn API scanning for automated security testing. Find vulnerabilities from broken authentication to business logic flaws in your endpoints.
Artemiy Malyshau
A complete guide to automated pentest tools and best practices. Learn what works, what doesn’t, and how to implement continuous security testing.
Artemiy Malyshau
Compare the best AI-powered application security testing tools. Find which tools detect business logic flaws and broken access control.
Artemiy Malyshau
Occasional updates, new content, and insights. No spam; unsubscribe anytime.
| Reads database structure and sensitive data from error messages displayed in application output |
| Database error messages appearing in HTTP responses, repeated failed queries with syntax variations |
| Blind (Boolean-Based) | Injects conditions that alter application behavior based on true/false results without displaying data directly | Reconstructs data bit-by-bit by observing different application responses to true versus false conditions | High volume of similar requests with minor variations, unusual query patterns testing character values sequentially |
| Blind (Time-Based) | Uses database sleep functions to create deliberate delays that reveal whether injected conditions are true or false | Infers data through response timing differences when conditions return true versus false | Abnormal response delays, queries containing SLEEP(), WAITFOR DELAY, or pg_sleep() functions |
| Out-of-Band | Exfiltrates data through alternative channels like DNS queries or HTTP requests when standard response channels are blocked or monitored | Sends data to attacker-controlled servers via DNS lookups, HTTP callbacks, or other protocol channels | Unexpected outbound DNS queries, HTTP requests to external domains from database server, firewall alerts for unusual protocols |
| Second-Order | Stores malicious SQL payload in the database that executes later when the application retrieves and uses that stored data in a subsequent query | Delayed execution extracts data when poisoned records are retrieved and used in queries without sanitization | Vulnerabilities appearing in administrative or reporting functions, attacks succeeding after data storage and retrieval cycle |
String concatenation bypasses this separation, making manual escaping unreliable.
Blind SQL injection bypasses standard detection because attacks leave no visible errors or output changes. Attackers extract data through response timing or subtle behavior differences instead of error messages.
Detection requires monitoring query execution patterns. Time-based attacks create abnormal delays as the database processes sleep functions. Boolean-based attacks generate unusual query volumes as attackers iterate through character values to reconstruct data one bit at a time.
Response time anomalies flag potential time-based probing. Web application firewalls configured to recognize sleep functions like SLEEP(), WAITFOR DELAY, and pg_sleep() catch many blind attempts before they succeed.
Prevention relies on parameterized queries, which eliminate the attack surface regardless of output visibility. Input validation blocking SQL keywords adds defense depth.
Input validation and sanitization create necessary security boundaries but never substitute for parameterized queries. Whitelist-based validation limits fields to expected formats (alphanumeric strings for usernames, numeric values for IDs), rejecting malformed input before it reaches query logic. Database accounts require minimum privileges that prevent DROP, CREATE, and administrative operations when injection succeeds.
Stored procedures reduce exposure only when they use parameterized statements internally. Calling procedures with concatenated strings recreates the vulnerability. Escaping functions like mysql_real_escape_string() handle specific characters but miss encoding variations across different contexts.
Blacklist approaches that block keywords like SELECT or UNION collapse when attackers apply case manipulation, encoding tricks, or alternate syntax. Layer these protections behind parameterized queries as your primary defense mechanism.
SQL injection persists because organizations create vulnerable code faster than they fix it. Legacy applications built before secure coding standards became widespread remain in production without remediation budgets. Rapid development cycles pressure teams to ship features over security reviews.
AI-generated code accelerates the problem. Only 10% meet security standards, even when features function correctly. Engineers using AI assistants write less secure code but trust the output more, creating a confidence gap where vulnerabilities slip through code review.
Third-party dependencies and frameworks sometimes bypass parameterized queries for performance or flexibility, reintroducing string concatenation patterns. Developer turnover means security knowledge doesn’t transfer consistently across teams.
Automated scanners like SQLMap, Burp Suite, and OWASP ZAP probe applications with payloads designed to trigger SQL injection behavior. These tools test input fields, URL parameters, cookies, and HTTP headers for injection points, generating reports of vulnerable endpoints.
Manual testing uncovers context-specific vulnerabilities that scanners miss. Penetration testers probe authentication flows, API endpoints, and complex query logic where automated tools lack business context to construct effective payloads.
Integrate security scanning into CI/CD pipelines so each code change triggers vulnerability checks before deployment. Static analysis flags unsafe query construction patterns during builds, while runtime scanning tests running applications in staging environments.
SQL injection vulnerabilities break code structure. Business logic vulnerabilities break intent. Parameterized queries solved the first problem by enforcing correct syntax, preventing user input from becoming executable code. Authorization flaws require understanding whether code enforces the security policy it should.
You can’t parameterize away a missing permission check. Pattern matching can’t tell you if an API endpoint verifies user ownership before returning data. Taint analysis tracks data flow but can’t determine whether conditional logic is correct. The gap between what applications should do and what they actually do is unique to each codebase.
Finding broken access control and IDOR vulnerabilities requires understanding call chains across services, mapping trust boundaries, and identifying where authorization checks should exist but don’t.
Preventing SQL injection in cyber security comes down to separating query structure from user input through parameterized statements. Input validation and scanning add layers of protection but never replace the primary defense of correct query construction. Your team needs to make safe coding patterns automatic so vulnerabilities don’t slip through during rapid development cycles. Testing catches issues before deployment, but building security into your workflow prevents them from appearing in the first place.
