Prisma Security Review with AI Prompts

Audit my Prisma code for unsafe raw query usage.

Find all instances of:

1. $queryRawUnsafe - always dangerous
2. $executeRawUnsafe - always dangerous
3. $queryRaw with string concatenation (not tagged template)
4. $executeRaw with string concatenation

For each issue found:

1. Show the vulnerable code
2. Explain the injection risk
3. 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.

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:

1. Prisma middleware to inject user filters
2. OR explicit where clauses in each query
3. 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

Find and fix data exposure issues in Prisma queries.

Problems to find:

1. Returning full user objects (including passwordHash)
2. Using select: undefined (returns all fields)
3. Including sensitive relations without filtering
4. Exposing internal IDs or metadata

For the User model with fields: id, email, passwordHash, stripeCustomerId, createdAt

Create:

1. A safe select object for public user data
2. A utility type for the safe user
3. Middleware to strip sensitive fields
4. 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

Security review of my Prisma schema.

Check for:

1. Sensitive fields that should have @db.Text (not exposed in errors)
2. Missing @@unique constraints that could cause issues
3. Cascade deletes that might delete too much
4. Fields that should use @default but don't
5. 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