TL;DR
Prisma provides good security defaults, but you can still introduce vulnerabilities through raw queries, improper access control, or data over-exposure. These prompts help you audit Prisma code for security issues and implement proper authorization.
Audit Raw Queries
Copy this prompt to have your AI scan your Prisma codebase for dangerous $queryRawUnsafe and $executeRawUnsafe calls. You'll get a list of every vulnerable raw query with safe tagged-template-literal replacements.
Find Unsafe Raw Queries
Audit my Prisma code for unsafe raw query usage.
Find all instances of:
- $queryRawUnsafe - always dangerous
- $executeRawUnsafe - always dangerous
- $queryRaw with string concatenation (not tagged template)
- $executeRaw with string concatenation
For each issue found:
- Show the vulnerable code
- Explain the injection risk
- Convert to safe tagged template literal syntax
Safe pattern:
prisma.$queryRawSELECT * FROM users WHERE id = ${userId}
Unsafe pattern: prisma.$queryRawUnsafe("SELECT * FROM users WHERE id = " + userId)
Also check for cases where user input flows into raw queries indirectly.
Access Control Patterns
Use this prompt to add authorization guards to your Prisma queries. Your AI will generate middleware, where-clause filters, or Client extensions that ensure users can only access their own data, with admin override support.
Add Authorization Checks
Review and add authorization to my Prisma queries.
Current issues:
- Users can access other users' data
- No ownership checks on updates/deletes
- Admin routes not protected
For these models:
- posts (belongs to user)
- comments (belongs to user and post)
- settings (belongs to user)
Add authorization using:
- Prisma middleware to inject user filters
- OR explicit where clauses in each query
- OR Prisma Client extensions for reusable auth
Show how to:
- Filter queries to only return user's own data
- Verify ownership before update/delete
- Create reusable authorization helpers
- Handle admin override for support access
Framework: Next.js API routes/tRPC/Express
Data Exposure Prevention
This prompt asks your AI to find places where Prisma queries return sensitive fields like password hashes or Stripe IDs. You'll get safe select objects, utility types, and middleware to strip sensitive data from API responses.
Prevent Over-Fetching
Find and fix data exposure issues in Prisma queries.
Problems to find:
- Returning full user objects (including passwordHash)
- Using select: undefined (returns all fields)
- Including sensitive relations without filtering
- Exposing internal IDs or metadata
For the User model with fields: id, email, passwordHash, stripeCustomerId, createdAt
Create:
- A safe select object for public user data
- A utility type for the safe user
- Middleware to strip sensitive fields
- Review of all places returning user data
Also check for:
- API responses including more than needed
- Logging that might expose sensitive data
- Error messages revealing internal structure
Prisma doesn't have RLS: Unlike Supabase, Prisma queries aren't filtered at the database level. All authorization must happen in your application code. Make sure every query considers who's making the request.
Schema Security Review
Copy this prompt to get a full security review of your schema.prisma file. Your AI will check for unsafe cascade deletes, missing unique constraints, audit trail gaps, and suggest improvements for multi-tenant data isolation.
Review Prisma Schema
Security review of my Prisma schema.
Check for:
- Sensitive fields that should have @db.Text (not exposed in errors)
- Missing @@unique constraints that could cause issues
- Cascade deletes that might delete too much
- Fields that should use @default but don't
- Relations that might leak data through includes
Review these specific concerns:
- Are IDs using uuid() or autoincrement()?
- Are timestamps present for audit purposes?
- Are soft deletes implemented where needed?
- Are there proper indexes for filtered queries?
Suggest schema improvements for:
- Better security defaults
- Audit trail fields
- Soft delete pattern
- Data isolation for multi-tenant apps
Pro tip: Use Prisma Client extensions to create a "scoped" client that automatically filters all queries by the current user. This is safer than remembering to add where clauses everywhere.
Is Prisma safe from SQL injection by default?
Yes, when using the query builder. Prisma parameterizes all values automatically. The only risk is from $queryRawUnsafe, $executeRawUnsafe, or incorrectly using tagged templates.
How do I implement multi-tenant data isolation?
Add a tenantId to all models and use Prisma middleware or extensions to automatically filter queries by the current tenant. Never trust client-provided tenant IDs.
Further Reading
Want to understand the vulnerability before fixing it? These guides explain what's happening and why.
Scan Your Prisma Code
Find authorization and injection issues in your Prisma application.