What is SQL injection? (and why input validation is non-negotiable)

What it actually is

SQL injection is what happens when text a user typed, a name, a search term, a password, ends up glued directly into the sentence your app sends to the database, instead of being handled as a separate piece of data. Think of it like a mail-merge letter with a blank for “[Name]”: if you don’t check what goes in that blank, someone can type “John, and also send my account $10,000” and the letter reads it as one continuous instruction instead of just a name. The database has no way to tell the difference between the query you meant to write and the extra command an attacker snuck in through the blank.

The textbook example is a login form. If the code builds a query like SELECT * FROM users WHERE username = '<input>' AND password = '<input>' by dropping in exactly what the user typed, someone can type ' OR '1'='1 into the username field. The query becomes true no matter what, and they’re logged in without a real password.

Why your AI just did this

When your agent wires a form, a search bar, or a filter up to a database, it has to build a query using whatever the visitor types. A careful agent does this with parameterized queries (also called prepared statements) or through an ORM like Prisma, Drizzle, or Supabase’s client library, all of which send your SQL and the user’s data on separate tracks, so the data can never be read as part of the command. A careless pass concatenates the input straight into the query string instead, gluing text together, which reopens the door.

This isn’t a rare slip. Research on AI-generated code, most thoroughly documented for GitHub Copilot, has found SQL injection or closely related flaws in a meaningful share of database-facing snippets, and the same pattern shows up in code from other assistants, including Claude. The agent isn’t being deliberately careless. “Make this form save to the database” doesn’t automatically imply “and make sure nothing typed into it can be read as a command,” so that protection has to be requested, not assumed.

When you’ll run into it

• You type a single quote ' into a search box or login field to test something, and the app throws a raw database error instead of handling it gracefully, a common sign the query wasn’t parameterized.
• A security scanner or code review flags “SQL injection” or “unsafe query” on a custom database function.
• Your agent writes supabase.from('table').select()-style calls: those are parameterized automatically. A custom Postgres function using EXECUTE with string concatenation is not, even though it lives in the same Supabase project.
• Someone brings up the classic ' OR '1'='1 trick and asks whether your login form falls for it.
• npm audit or a linter warns about a query built by joining strings together instead of using placeholders.

What to check

• Ask your agent directly: does this query use parameterized queries or prepared statements, or is user input joined into the SQL string?
• Confirm any custom Postgres/RPC function uses EXECUTE ... USING instead of concatenating text into the query.
• Search your codebase for raw SQL built with +, template literals, or string formatting, each one is a candidate worth rewriting.
• Don’t rely on row-level security alone. RLS decides which rows a logged-in user can see, it does nothing to stop an injected query from running in the first place.
• Test every field that touches the database with a single quote '. An unhandled database error means the input isn’t being treated as pure data.

Say it like a dev

Instead of: “make sure hackers can’t mess with my database through the form” Say: “make sure this query is parameterized, not built by joining strings together”

Instead of: “add security to my search bar” Say: “add input validation, and confirm the query uses prepared statements”

Instead of: “is my app safe from database attacks” Say: “does any function build SQL with string concatenation, and if so, does it use EXECUTE … USING instead?”