Why AI-generated SQL is full of injection vulnerabilities

The pattern AI learned first

String concatenation is everywhere in public code. Stack Overflow answers from 2009, tutorial blog posts, quick scripts thrown on GitHub, legacy codebases scraped into training sets. When you ask an AI assistant to write a database query, it reaches for what it saw most often. That is concatenation.

The model is not trying to hurt you. It is pattern-matching against a corpus where the vulnerable version is more common than the safe one.

Here is what you get from most AI assistants when you ask for a simple user lookup:

// What your AI assistant gives you
const query = `SELECT * FROM users WHERE email = '${userEmail}'`;
db.query(query);

That one line is a SQL injection vulnerability. If userEmail comes from user input (and it does), an attacker sends ' OR '1'='1 and gets every row in your users table. They send '; DROP TABLE users; -- and you find out how current your backups are.

The fix is not complicated:

// What you should have
const query = `SELECT * FROM users WHERE email = ?`;
db.query(query, [userEmail]);

Parameterised queries separate SQL structure from data. The database driver handles escaping. The attacker's input becomes a literal string, not executable SQL.

Why AI defaults to the wrong approach

There are a few reasons training data skews toward concatenation. Quick examples get written without the discipline of production code. Tutorials optimise for readability over correctness. And parameterised query syntax varies across databases and libraries in ways that make it harder to extract a consistent pattern from millions of examples.

There is also something subtler. String interpolation is shorter. Shorter code tends to score better on forums, which shapes the reward signal. So the model learns that the compact version is the idiomatic one.

When an AI generates code, it is optimising for patterns it has seen reinforced. SQL injection vulnerabilities have been in public code for thirty years. The model saw them constantly. It learned that they are normal.

They are not.

The attack surface is larger than you think

The problem compounds because injection vulnerabilities do not stay isolated. A single parameterisation miss in a search endpoint can expose your entire database. An attacker who can inject into one query can often chain it to read other tables, exfiltrate data incrementally, or write files if the database user has sufficient permissions.

Modern SQL injection attacks are also largely automated. Tools like sqlmap can probe an endpoint and dump an entire database schema in minutes without any manual payload crafting. Your application does not need to be a high-value target for someone to run a scan against it.

I have looked at production code from teams who were clearly using AI assistants throughout development, and the injection patterns are consistent: string interpolation in search handlers, in filter queries, in any endpoint that takes a user-supplied value. It is not that the developers were careless. They trusted the generated code and moved on.

What to actually do

You have a few options here, and none of them are perfect on their own.

The most obvious is to prompt explicitly for parameterised queries in every request. Put it in your system prompt if your tool supports that. This helps, but it is fragile because the model can still drift toward concatenation in longer or more complex generated code.

A more durable fix is to adopt a query builder or ORM that makes parameterisation the structural default. Libraries like Drizzle, Prisma, or Knex with typed bindings force the right pattern at the API level. The AI generates code that calls the library, and you get injection resistance without relying on the model to remember.

But regardless of what you do at the generation stage, you need static analysis. Human code review misses injection vulnerabilities because the pattern is often subtle, especially when a user-supplied value is three function calls away from where it reaches the query. Automated scanning finds the structural issue: untrusted input reaching a query construction point without passing through a parameterised binding.

The honest picture

AI coding tools are not going away, and I am not arguing they should. But the optimism around them has been running ahead of the security reality.

The pitch is that AI assistants make you faster. They do. They also produce code that compiles, passes type-checks, and sometimes even passes tests, while containing vulnerabilities that have been well-understood since before most current developers started writing code. SQL injection appears in every version of the OWASP Top 10. It keeps appearing because AI-generated code in 2025 carries the same problems as the tutorial code from 2005 that trained the model.

You cannot fix this by being more careful at the prompt level alone. You need tooling that catches it after the fact.

Seaworthy flags this pattern automatically as part of its data exposure checks.