Is my AI-built app open to SQL injection?
Less often than older apps, because most AI-built apps use a database client or ORM that parameterizes queries. It still appears where generated code builds SQL strings: search, sorting, filters, reports and database functions written to make a feature work. Search your code for queries assembled with user input and replace them with parameters.
Where it hides
- Search boxes and filters built as raw SQL.
- Sort and column names taken from the request, which cannot be parameterized and must be allow-listed.
- Database functions (RPC) built with string concatenation.
- AI features that generate SQL from natural language and run it. See improper output handling.
The fix
Parameterized queries for values, allow-lists for identifiers like column names, and a database role with the minimum permissions. If an AI feature generates queries, run them with a read-only role scoped to the user's data.
When the AI writes the SQL
A growing pattern: a feature lets users ask questions in plain language and the model writes a SQL query that the app runs. This is SQL injection by design, because the attacker can ask the model to write any query. If you build this, run generated queries with a database role that can only read, only the tables the feature needs, and only the current user's or organization's rows, enforced by row level security rather than by the model including a filter. Set a timeout and a row limit. Never let generated SQL write, alter or delete.
Test it by asking the feature for other users' data, for table and column names, and for queries that are expensive to run. Each one that works is a finding.
Getting it checked
TrazTech offers vibe-coding QA and security review, listed from $2,000 CAD. Get at least one other quote on the same scope; the questions to ask a testing firm help compare them.
Related questions
Get a scope for your app
Tell us what you built, what it stores and who is about to use it.
Get matchedCommon questions
Does Supabase prevent SQL injection?
Its client builds parameterized requests. Custom SQL functions you write can still be injectable.
Will a scanner find it?
Scanners find some cases. A code review finds the rest faster.