On this page
  1. What is SQL injection?
  2. How it works
  3. Why AI-generated code keeps writing it
  4. How to prevent it
  5. Where AI coding assistants get this wrong
  6. Checklist
  7. FAQ
    1. What is a parameterized query?
    2. Is using an ORM enough?
    3. What is the difference between SQL injection and XSS?
  8. Related topics
  9. Sources
concept

What Is SQL Injection (and Why Does AI-Generated Code Keep Writing It)?

SQL injection lets attackers run arbitrary database commands through your app. Learn how it works and why AI-generated code repeatedly introduces it.

Information Securitybeginner8 min readUpdated 2026-08-15

Quick answer

  • SQL injection happens when untrusted input is concatenated into a database query, letting attackers run their own SQL.
  • The fix is parameterized queries, which keep data and commands separate.
  • AI assistants still emit string-built queries frequently, making this a top recurring flaw in generated code.

What is SQL injection?

SQL injection is a vulnerability that lets an attacker manipulate the SQL queries your application sends to its database by injecting input the database interprets as code. If a login query is built by string concatenation — "SELECT * FROM users WHERE name = '" + input + "'" — an attacker who enters ' OR '1'='1 turns it into a query that returns every user. It is CWE-89 and sits under A03 Injection in the OWASP Top 10.

How it works

The database cannot distinguish the parts of a query the developer wrote from the parts an attacker supplied, because they arrive as one string. The attacker closes the intended context (with a quote) and appends new SQL, such as '; DROP TABLE users; --. Depending on the query, injection can read data, bypass authentication, modify records, or in the worst case run operating-system commands through the database.

Why AI-generated code keeps writing it

Assistants learn from training data that includes many vulnerable examples, and when asked for a quick “query the user by name” snippet they often reach for the simplest form — string concatenation or f-strings — unless explicitly told to parameterize. The pattern is seductive because it’s short and appears to work. This is one of the clearest documented cases of AI models reproducing a well-known vulnerability class.

How to prevent it

Use parameterized queries (prepared statements), which send the SQL and the data separately so input can never become code:

cursor.execute("SELECT * FROM users WHERE name = %s", (name,))

For dynamic table or column names, use an explicit allow-list of valid identifiers rather than interpolation.

Where this bites vibecoders

The typical flow: the assistant writes an endpoint with an f-string query, the app works in the demo, and the vulnerability ships. Because the bug is invisible in normal use, the only thing that catches it is review or scanning. If your code builds SQL from strings, that’s the bug — not a style choice. Make parameterized queries a non-negotiable default in every prompt and review.

Where AI coding assistants get this wrong

  • Using f-strings or concatenation for queries by default.
  • Parameterizing the value but interpolating table/column names unsafely.
  • Generating ORM code that falls back to raw SQL for a “quick” case, reintroducing the flaw.
  • Confusing escaping/quoting input with proper parameterization.

Checklist

  • Use parameterized queries or an ORM’s safe methods everywhere.
  • Allow-list any dynamic identifiers (table/column names), never interpolate.
  • Scan for string-built SQL in review and with SAST tools.
  • Test inputs containing quotes and SQL fragments against every endpoint.
  • Apply least-privilege database accounts so a breach is contained.

FAQ

What is a parameterized query?

A parameterized query (prepared statement) separates the SQL structure from the data values. The database compiles the query first, then binds values as data, so input can never be interpreted as SQL. It is the definitive fix for injection.

Is using an ORM enough?

An ORM helps but isn’t a guarantee. ORMs prevent most injection when used with their standard query builders, but raw SQL passthroughs and unsafe string interpolation still allow it. Treat raw SQL inside an ORM with the same suspicion as raw SQL anywhere.

What is the difference between SQL injection and XSS?

SQL injection attacks the database through the query; cross-site scripting (XSS) attacks other users through the browser by injecting client-side script. Both are injection, but they target different layers and use different defenses.

Sources

Tags:SQL InjectionWeb SecurityAI Coding
Share: