What Is SQL Injection

SQL injection is a vulnerability that allows an attacker to execute arbitrary SQL statements when user input is incorporated into database queries without proper processing. It has been a fixture of the OWASP Top 10 for many years and is one of the most dangerous web vulnerabilities, potentially leading to theft, modification, or deletion of all data in the database, and even OS command execution on the server.

First publicly reported in 1998, SQL injection remains a primary attack method against web applications more than a quarter century later. Despite the fundamental countermeasure being well-known, vulnerabilities persist due to implementation flaws.

Attack Principles and Types

SQL injection occurs when an application constructs SQL queries through string concatenation. For example, if a username entered in a login form is directly embedded in a query like SELECT * FROM users WHERE name = 'input', an attacker can enter ' OR '1'='1 to make the WHERE clause always true, bypassing authentication.

Main Attack Types

UNION-based: Injects UNION SELECT to retrieve data from tables that should not be accessible. Requires matching column count and types, but these can be inferred from error messages or response variations
Error-based: Intentionally triggers errors and reads database information (table names, column names, data) from error messages
Blind SQL injection: When error messages are not displayed, extracts information bit by bit using Boolean-based conditional branching or Time-based response time differences
Out-of-Band: Sends data from the database to an external server via DNS requests or HTTP requests

Automated tools like sqlmap make it possible to detect and exploit SQL injection without advanced technical knowledge.

Real-World Impact and Scope of Damage

Damage from SQL injection extends far beyond data theft.

Data theft: All data stored in the database - personal information, credentials, credit card numbers - can potentially be leaked
Data modification and deletion: UPDATE or DELETE statements can be injected to modify or delete data. Entire tables can be dropped with DROP TABLE
Authentication bypass: Manipulate login queries to log in as any account (including administrators) without knowing the password
Server takeover: Exploit database features (MySQL's LOAD_FILE, SQL Server's xp_cmdshell, etc.) to execute OS-level commands

Many major data breaches have involved SQL injection. Detection by a WAF is an effective supplementary measure, but techniques to bypass WAFs through clever encoding and comment insertion are known, so it cannot replace fundamental countermeasures.

Fundamental Countermeasures

The fundamental countermeasure for SQL injection is clear, and when implemented correctly, the vulnerability can be completely eliminated.

Prepared Statements (Parameterized Queries)

Separates the SQL statement structure from data, preventing user input from being interpreted as SQL syntax. This is the most reliable and recommended countermeasure. All database access libraries support prepared statements.

Using an ORM

Using an ORM (Object-Relational Mapping) reduces opportunities to write SQL directly, lowering the risk of SQL injection. However, when using raw query features or custom queries in an ORM, the same precautions as with prepared statements are necessary.

Defense in Depth

Principle of least privilege: Minimize the privileges of the database account used by the application. Use read-only accounts for read-only operations
Input validation: Accept only numbers for numeric fields, only proper formats for email fields, etc. However, this is a supplementary measure and cannot replace prepared statements
Error message control: Do not display database error messages directly to users. Prevents information leakage through error-based SQL injection
Vulnerability management: Detect SQL injection vulnerabilities early through regular security scans and code reviews
Security header configuration: Not a direct SQL injection countermeasure, but strengthens the overall security posture

To learn more about this topic, see API Security Basics: Protecting the Backend of Web Services.

Common Misconceptions

Escaping input values prevents SQL injection: Escape processing is prone to implementation errors, with gaps arising from character encoding differences and special cases. Prepared statements fundamentally separate SQL structure from data, eliminating the risk of escaping oversights. Use prepared statements, not escaping.
NoSQL databases are immune to SQL injection: While SQL injection does not occur, a similar vulnerability called NoSQL injection exists. In MongoDB, directly embedding user input in JSON queries allows injection of query operators. Regardless of database type, proper handling of user input is essential.

SQL Injection vs. XSS Comparison

SQL Injection

Targets the server-side database. Can steal, modify, and delete data. Fundamentally prevented with prepared statements. Damage affects server-side data.

XSS

Targets the client-side browser. Primary damage includes cookie theft and session hijacking. Defended with output escaping and CSP. Damage occurs in the user's browser.

SQL Injection