Node.js Permissions the Right Way: RBAC with Express and Prisma

Summary

The video demonstrates a project-scoped role-based access control (RBAC) design for an Express and Prisma application. It addresses common authorization failures that can pass ordinary code review but fail a security review.

Core design

• Store roles on project membership, not on the user. A user’s role depends on the project. The example replaces a role column on the user with a ProjectMember model keyed by project ID and user ID, with roles such as owner, editor, and viewer.
• Centralize authorization decisions. A typed permissions map defines what each role can do. A shared authorize function checks a user’s project membership and permissions, while requirePermissions middleware applies those checks to routes. Non-members receive 404 to avoid revealing that a resource exists; members without the required permission receive 403.
• Check that child resources belong to the authorized project. The demo uncovers a vulnerability where Bob, authorized for Project B, can delete Alice’s task in Project A because the handler looks up the task by ID alone. The fix is to scope task updates and deletions to both the task ID and project ID. For deletion, Prisma’s deleteMany lets the handler return 404 when no matching task exists.
• Keep roles out of JWTs. Tokens contain the user ID, while the database supplies the current project membership and role on each protected request. This makes demotions take effect immediately, without waiting for a token to expire or issuing a new one, at the cost of an additional database lookup. Account deletion or blocking remains subject to token lifetime.
• Make permission checks hard to omit. A routing helper requires each route to declare a permission or an explicit public-route marker. An ESLint rule prevents routes from being registered outside that helper, while TypeScript catches missing or mistyped permissions. The presenter recommends running linting and type checks in hooks so AI coding agents encounter and fix errors in their own workflow.
• Test expected outcomes independently. The tutorial builds a Vitest/Supertest test matrix for owners, editors, viewers, third parties, and cross-project task IDs. Expected status codes are written manually rather than derived from the permissions map, so an incorrect permission change—such as allowing viewers to delete tasks—causes a test failure.
• Choose complexity only when needed. This RBAC approach suits many products, but more complex needs—such as customer-defined roles, inherited permissions, or sharing resources outside a project—may warrant a dedicated authorization tool. Castle and OpenFGA are mentioned as possible options.

Practical takeaway

Search for checks such as req.user.role and ask, “Role for what?” Then test a sensitive nested route using a resource from another user’s project; the expected result is 404, not successful access.

Main speaker and source

Alex Rusin presents the Express and Prisma tutorial. Claude Code is used during the demonstration to generate and modify code.