What it is
Injection happens when data from a user is handed to an interpreter that cannot tell data from instructions. A name typed into a form ends up inside a SQL statement, a shell command, a JavaScript eval, a MongoDB query object, or an HTML page, and the interpreter runs it. Cross-site scripting is injection into the browser; SQL injection is injection into the database; the pattern is identical.
It dropped to fifth in 2025 after decades near the top, mostly because ORMs and frameworks now escape by default. It is still on the list because the defaults get bypassed the moment someone builds a query by hand.
How it shows up in AI-generated code
AI tools know about parameterised queries and use them most of the time. The failures come in the corners: a dynamic ORDER BY, a search with LIKE, a report query too complex for the ORM, a shell call to a CLI tool. There the model falls back to string concatenation because it is the shortest code that works. In our scans, code injection via eval and command injection via a shell were both in the top eight high-severity findings, and SQL by string concatenation affected 40 repos.
React apps get their own variant: dangerouslySetInnerHTML with user content, because the tool needed to render HTML from a CMS or a markdown converter and that is the prop that does it. The name is a warning that gets copied along with the code.
Example: A search endpoint built by hand
const rows = await db.query(
`SELECT * FROM products WHERE name LIKE '%${req.query.q}%' ORDER BY ${req.query.sort}`
);const SORTS = { name: "name", price: "price" } as const;
const sort = SORTS[req.query.sort as keyof typeof SORTS] ?? "name";
const rows = await db.query(
`SELECT * FROM products WHERE name LIKE $1 ORDER BY ${sort}`,
[`%${req.query.q}%`]
);Parameters handle values. Identifiers like column names cannot be parameterised, so they go through an allow-list. AI tools usually get the first half and miss the second.
How to find it
- Search for query strings built with + or template literals that include a variable from a request.
- Search for exec, spawn, system, subprocess with any argument derived from input.
- Search for eval, new Function, and dangerouslySetInnerHTML.
- For MongoDB, look for a request body passed straight into find or where.
- Prbl rules PRBL-I001 through I005 cover SQL, command, code, NoSQL injection and prototype pollution; the XSS fix guides cover the React side.
How to fix it
- Parameterise every query. For identifiers, allow-list.
- Never pass user input to a shell. Call the program directly with an argument array, or do not shell out at all.
- Delete eval. There is almost always a safer construct.
- Validate request bodies against a schema before they touch a query builder.
- Sanitise HTML with a real library before rendering it, and prefer rendering text.
What Prbl checks for this category
Run a free scan on a public repo or a live URL. Findings link to the fix guides below.
Fix guides for this category
Go deeper
Common questions
If I use an ORM am I safe from SQL injection?
Mostly. ORMs parameterise the queries they generate. The risk is the raw query escape hatch, which every ORM has, and which AI tools reach for when the query gets complicated. Search your code for raw, query, execute and $queryRaw and review each one.
Is XSS really injection?
Yes. The interpreter is the browser and the payload is HTML or JavaScript. OWASP folded cross-site scripting into the injection category in 2021 and it stays there in 2025. In React the usual door is dangerouslySetInnerHTML.
Why did injection fall down the list?
Frameworks and ORMs escape by default now, so the baseline is safer than it was in 2013. It is still fifth because the manual paths remain, and AI tools use them more than a careful human would.