SQL Injection

What is SQL injection?

SQL injection (SQLi) is an attack where someone manipulates the database queries your application sends by inserting malicious SQL code through user input. It works because the application treats untrusted user input as part of a database command instead of as data.

Here's the classic example. Your login form takes a username and password and builds a query like this:

SELECT * FROM users WHERE username = 'INPUT' AND password = 'INPUT'

If an attacker enters ' OR '1'='1 as the username, the query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''

Since '1'='1' is always true, the database returns all users and the attacker is logged in without knowing any credentials. That's SQL injection in its simplest form.

The attack isn't limited to login forms. Any place your application passes user input to a database query is a potential injection point: search bars, URL parameters, API endpoints, form fields, HTTP headers, and even cookies.

Types of SQL injection

1. In-band (classic) SQLi. The attacker sends malicious SQL and sees the results directly in the application's response. This is the most straightforward type and includes error-based SQLi (using database error messages to extract information) and UNION-based SQLi (combining results from multiple queries).
2. Blind SQLi. The application doesn't display database errors or query results, so the attacker infers information by asking the database true/false questions and observing how the application responds. It's slower but equally effective.
3. Out-of-band SQLi. The attacker triggers the database to send data to an external server they control. This works when the application doesn't return query results in its response and timing-based blind techniques aren't reliable.

Why SQL injection still matters

SQL injection was first documented in 1998. Twenty-seven years later, it remains one of the most dangerous and frequently exploited vulnerability classes in web applications.

1. It's still everywhere. MITRE's 2025 CWE Top 25 ranks SQL injection (CWE-89) as the #2 most dangerous software weakness. The OWASP Top 10:2025 lists injection as the #5 risk category, with SQL injection accounting for over 14,000 CVEs alone.
2. It's actively exploited at scale. CISA has added multiple SQL injection CVEs to its Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation in the wild. The Verizon 2024 DBIR found that web application attacks remain one of the top breach patterns, with injection (including SQLi) as a primary attack vector.
3. The consequences are severe. A successful SQL injection attack can give an attacker full read/write access to your database. That means customer data, credentials, payment information, and any other data your application stores. The attacker can also modify or delete data, escalate privileges, and potentially execute operating system commands.
4. Governments are losing patience. In March 2024, CISA and the FBI issued a joint Secure by Design alert specifically about SQL injection, calling it "unacceptable" that vendors continue to ship products with these flaws despite decades of available mitigations.

Real-world SQL injection breaches

SQL injection has been behind some of the most damaging data breaches in history:

• MOVEit Transfer (2023). A SQL injection vulnerability (CVE-2023-34362) in the MOVEit file transfer platform was exploited by the Cl0p ransomware group, affecting thousands of organizations worldwide. Victims included British Airways, the BBC, and multiple U.S. government agencies.
• Equifax (2017). While the root cause involved an unpatched Apache Struts vulnerability, the attack exploited injection techniques that led to the exposure of 143 million customer records, including Social Security numbers. Remediation costs exceeded $1.3 billion.
• TSA FlyCASS (2024). Researchers discovered a SQL injection vulnerability in the FlyCASS system used by airlines to manage crew access to TSA security checkpoints. The flaw could have allowed unauthorized individuals to add themselves to airline crew databases.

Preventing SQL injection

The good news: SQL injection is almost entirely preventable with known techniques.

• Use parameterized queries (prepared statements). This is the single most effective defense. Parameterized queries separate the SQL command from the data, making it structurally impossible for user input to be interpreted as SQL code. Every modern programming language and database driver supports them.
• Use an ORM. Object-relational mappers like Sequelize, SQLAlchemy, Prisma, and ActiveRecord generate parameterized queries by default. If your team uses an ORM and avoids raw SQL, you've eliminated most SQL injection risk without thinking about it.
• Validate and sanitize input. Input validation is a defense-in-depth measure, not a primary defense. Reject input that doesn't match expected patterns (e.g., a numeric ID field should only accept numbers). But never rely on input validation alone, because there will always be edge cases.
• Apply least privilege to database accounts. Your application's database user should have the minimum permissions required. If the application only reads data from a table, the database user shouldn't have write or delete permissions on that table. This limits the damage if an injection does succeed.
• Scan your code. Static analysis (SAST) tools can detect SQL injection patterns in your codebase before they reach production, including unsafe string concatenation in database queries.

How Fencer helps with SQL injection

Fencer's SAST scanning detects SQL injection patterns in your source code on every pull request, catching unsafe query construction before it merges. Fencer's DAST scanning tests your running application for SQL injection vulnerabilities by sending crafted requests to your endpoints, the same way an attacker would probe them. Together, these catch SQL injection at both the code level and the runtime level.