Prisma Client is parameterized by default. The typed query methods (findMany, update, and the rest) compile to bound SQL, and the tagged-template raw API ($queryRaw and $executeRaw) parameterizes its interpolations. Injection appears in two specific places: the explicit Unsafe raw methods, which take a plain string, and where/filter arguments that are built from an untrusted object.

Where it goes wrong#

• Raw query injection: $queryRawUnsafe and $executeRawUnsafe accept a string, so input concatenated into them injects SQL. The safe tagged-template $queryRaw is a short edit away, and mixing the two is the mistake.
• Filter injection: spreading a request object into a where lets the caller supply Prisma operators and relation filters, changing which rows match beyond what the endpoint intended.

The safe and unsafe paths side by side#

Prisma makes the boundary unusually visible: the dangerous methods carry Unsafe in their names. $queryRaw\...`binds every${}; $queryRawUnsafe(str)runsstras given. The subtler case is the typed API itself, which is injection-safe for values but trusts the shape of thewhere` object, so an endpoint that forwards attacker JSON into it is handing the caller control of the query structure rather than just a value.

References#

• Prisma: Raw queries
• OWASP: SQL Injection