What Is SQL Injection? The Complete Guide for AI-Assisted Developers

Why AI Coders Need to Know This

SQL injection is ranked #3 on the OWASP Top 10 (2021) — the authoritative list of the most critical web application security risks. According to security research, SQL injection accounts for approximately 23% of all critical web vulnerabilities discovered annually. In 2024, the Snowflake breach exploited stolen credentials partly enabled by SQL injection patterns, affecting over 160 companies.

For AI-assisted developers, the risk is specific and measurable. A 2025 Stanford study found that developers using AI coding assistants produced significantly more security vulnerabilities than those coding manually — and SQL injection was among the most frequent. The reason is straightforward: AI tools optimize for "code that works," not "code that is secure." A login query that uses string concatenation works perfectly in testing. It just also works perfectly for attackers.

If you build anything with a database — user accounts, form submissions, search features, admin panels — SQL injection is the first security concept you must understand. Not because you need to become a security expert, but because you need to recognize when AI has written dangerous code.

How SQL Injection Works

The attack exploits a simple programming mistake: putting user input directly into a SQL query string.

The vulnerable code

// ❌ VULNERABLE — user input goes directly into the SQL string
app.post('/login', async (req, res) => {
  const { username, password } = req.body;

  const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;

  const result = await db.query(query);

  if (result.rows.length > 0) {
    res.json({ message: 'Login successful' });
  } else {
    res.status(401).json({ message: 'Invalid credentials' });
  }
});

This looks correct. If a normal user types chuck and mypassword, the query becomes:

SELECT * FROM users WHERE username = 'chuck' AND password = 'mypassword'

That works fine. Now watch what happens when an attacker types this as the username:

' OR '1'='1' --

The query becomes:

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

Let's break that down:

• username = '' — no match, but that does not matter because of the next part
• OR '1'='1' — this is always true, so the WHERE clause matches every row
• -- — this is a SQL comment, which disables the rest of the query (the password check)

The attacker just logged in as the first user in the database — usually the admin — without knowing any password. The application happily returned "Login successful" because the query returned rows.

Real Scenario

You asked Claude Code to build a user search feature for your app. Users type a name into a search box and see matching results. The AI generates a quick implementation.

Build a user search API endpoint:
- GET /api/search?name=chuck
- Search the users table for matching names
- Return id, name, and email
- Use parameterized queries to prevent SQL injection
- Show me both the vulnerable version and the safe version so I understand the difference

Notice the explicit "use parameterized queries to prevent SQL injection" instruction. Without that line, AI will often generate the vulnerable version first. Adding security requirements to your prompts is one of the most impactful habits you can build.

What AI Generated

The vulnerable version (what AI often generates by default):

// ❌ VULNERABLE — string concatenation
app.get('/api/search', async (req, res) => {
  const name = req.query.name;
  const query = `SELECT id, name, email FROM users WHERE name LIKE '%${name}%'`;
  const result = await db.query(query);
  res.json(result.rows);
});

An attacker could search for: %'; DROP TABLE users; --

That becomes:

SELECT id, name, email FROM users WHERE name LIKE '%%'; DROP TABLE users; --%'

Your entire users table is deleted. Game over.

The safe version (parameterized query):

// ✅ SAFE — parameterized query
app.get('/api/search', async (req, res) => {
  const name = req.query.name;
  const query = 'SELECT id, name, email FROM users WHERE name LIKE $1';
  const result = await db.query(query, [`%${name}%`]);
  res.json(result.rows);
});

The difference: $1 is a parameter placeholder. The database engine receives the SQL structure and the data value separately. No matter what the user types, the database treats it as a literal string value, never as SQL code. The attacker's payload becomes a harmless search for the literal text %'; DROP TABLE users; --%.

Understanding Each Part

Why string concatenation is dangerous

String concatenation mixes code and data. When you write `SELECT * FROM users WHERE name = '${name}'`, the database cannot distinguish between "this is the query structure" and "this is the user's data." It parses the whole string as SQL. If the user's input contains SQL syntax, it becomes part of the query.

How parameterized queries work

Parameterized queries separate the two concerns:

1. The query template: SELECT * FROM users WHERE name = $1 — this is compiled as SQL structure.
2. The parameter values: ['chuck'] — these are always treated as data, never as code.

The database engine compiles the query plan first, then plugs in the values. Even if a value contains SQL syntax like '; DROP TABLE, the database treats every character as a literal string. It is fundamentally impossible to inject SQL through a parameterized query.

ORM protection

ORMs like Prisma and Drizzle use parameterized queries internally for all standard operations:

// Prisma — automatically parameterized
const users = await prisma.user.findMany({
  where: {
    name: { contains: searchTerm }
  }
});

// Drizzle — automatically parameterized
const users = await db.select()
  .from(usersTable)
  .where(like(usersTable.name, `%${searchTerm}%`));

Both generate parameterized SQL under the hood. This is one major reason ORMs are recommended for AI-assisted development: the security comes built-in.

The exception: raw query methods bypass ORM protection:

// ❌ VULNERABLE — even in Prisma, raw queries can be unsafe
const result = await prisma.$queryRawUnsafe(
  `SELECT * FROM users WHERE name = '${searchTerm}'`
);

// ✅ SAFE — use the safe raw query method with parameters
const result = await prisma.$queryRaw`
  SELECT * FROM users WHERE name = ${searchTerm}
`;

Types of SQL Injection

Classic injection (in-band)

The attacker sees the results directly in the application's response. The login bypass example above is classic injection — the app tells the attacker whether the injection worked by logging them in or returning data.

Blind injection

The application does not display query results, but the attacker can infer information from behavior differences. For example, if injecting ' AND 1=1 -- returns a 200 status and ' AND 1=2 -- returns a 404, the attacker knows the injection is working and can extract data one bit at a time.

Union-based injection

The attacker uses UNION SELECT to append a second query that reads from a different table. If your search returns user names, the attacker can make it also return passwords, emails, or any other data in the database.

-- Attack payload in a search field:
' UNION SELECT id, password, email FROM admin_users --

Time-based injection

The attacker injects a query that causes a deliberate delay (like pg_sleep(5) in PostgreSQL). If the response takes 5 seconds longer, the injection is working. This is used when the application reveals nothing in its response — not even different status codes.

What AI Gets Wrong About SQL Injection

Generating string concatenation by default

The #1 issue. AI tools generate `SELECT * FROM users WHERE id = ${id}` because it is simpler and shorter than the parameterized version. It works in testing. It is a critical vulnerability in production.

Input validation as the only defense

AI sometimes generates input sanitization (stripping quotes, escaping characters) as the SQL injection fix. Input validation is good practice, but it is not sufficient as the primary defense. Parameterized queries are the real fix. Validation is a secondary layer.

Trusting internal data

AI assumes data from "internal" sources (URL parameters, hidden form fields, cookies) is safe. It is not. Any data that touches the client can be modified by an attacker. Parameterize all user-influenceable data, not just obvious form fields.

Using ORMs unsafely

AI generates prisma.$queryRawUnsafe() for complex queries and drops in string interpolation. The method name literally contains "Unsafe" as a warning, but AI tools overlook it. Always use prisma.$queryRaw with tagged template literals instead.

Forgetting LIKE queries

Search features are the most common source of SQL injection in AI-generated code because LIKE '%${search}%' looks natural but is vulnerable. The fix: LIKE $1 with [`%${search}%`] as the parameter.

How to Audit for SQL Injection With AI

The code search

Search your codebase for these patterns — any match is a potential vulnerability:

# Search for string interpolation in SQL queries
grep -rn "SELECT.*\${" --include="*.js" --include="*.ts" .
grep -rn "INSERT.*\${" --include="*.js" --include="*.ts" .
grep -rn "UPDATE.*\${" --include="*.js" --include="*.ts" .
grep -rn "DELETE.*\${" --include="*.js" --include="*.ts" .
grep -rn "queryRawUnsafe" --include="*.js" --include="*.ts" .

The security audit prompt

Review this code for SQL injection vulnerabilities:
[paste your database query code]

For each query:
1. Is user input used directly in the SQL string?
2. Are parameterized queries used correctly?
3. Are there any raw SQL methods that bypass ORM protection?
4. Show me the fixed version of any vulnerable queries.

Manual testing

For any input field that queries a database, try entering:

• ' (single quote) — if you get a database error, the input is being used in SQL unsafely
• '; -- — if the behavior changes, injection is likely possible
• ' OR '1'='1 — if this returns more results than expected, you have confirmed injection

Only test on your own applications. Testing for SQL injection on systems you do not own is illegal in most jurisdictions.

Automated tools

• sqlmap: An open-source penetration testing tool that automates SQL injection detection and exploitation. Use it to test your own applications.
• OWASP ZAP: A free web application security scanner that checks for SQL injection and other vulnerabilities.
• Snyk: Scans your code and dependencies for known vulnerabilities including SQL injection patterns.

The SQL Injection Prevention Checklist

1. Use parameterized queries for every database operation that includes user input. No exceptions.
2. Use an ORM (Prisma, Drizzle, Sequelize) for standard CRUD operations. They parameterize automatically.
3. Never use queryRawUnsafe with user input. Use tagged template literals instead.
4. Validate input types as a secondary defense. If you expect a number, parse it as a number before using it.
5. Apply least privilege to your database user. The app's database user should not have DROP TABLE permissions.
6. Search your codebase for SELECT.*\${ patterns after any AI generates database code.
7. Test with a single quote in every input field before deploying.

What to Learn Next

• Security Basics for AI Coders — The broader security picture for AI-assisted development.
• Common Security Vulnerabilities — XSS, CSRF, and other attacks beyond SQL injection.
• What Is SQL? — Understand the language that SQL injection exploits.
• What Is an ORM? — ORMs prevent SQL injection by default — understand how.

FAQ