rls-patterns

Row Level Security (RLS) patterns enforce data isolation by wrapping Prisma queries with context helpers—withUserContext, withAdminContext, or withSystemContext—that automatically scope database operations to the appropriate user, admin, or system level, preventing unauthorized data leakage across user boundaries.

RLS applies to user-specific data tables including user profiles, payments, subscriptions, and enrollments, plus admin and system tables. Each table requires a defined security policy to ensure operations respect the calling context and prevent cross-tenant or privilege-escalation access.

No. RLS patterns forbid direct Prisma calls in API routes, webhook handlers, and data-access layers. All database operations must route through context wrappers to guarantee policy-compliant isolation and prevent accidental data exposure.

ESLint-based enforcement detects violations of RLS patterns, flagging direct Prisma calls and improper context usage. Combined with runtime rendering requirements for admin pages, this dual-layer approach ensures Row Level Security policies stay applied throughout development and production.

Yes. Webhook handlers that write to the database must wrap operations with the appropriate context helper—withSystemContext for webhooks triggered by external events—to maintain consistent data isolation and prevent database writes outside the intended security scope.

withUserContext scopes queries to a specific user's data, withAdminContext grants privileged read/write access for administrative operations, and withSystemContext allows system-level background tasks to interact with data without user or admin constraints, each enforcing distinct RLS boundaries.