Implement Static RBAC in React

---
name: "static-rbac-react"
description: "Model roles and permissions in React, protect routes and components consistently, and test static client-side access rules without confusing UI gating with server authorization."
---

# Implement Static RBAC in React

Use this skill when a React application has a stable set of roles and permissions that must control navigation, routes, and component actions.

## Security boundary

Client-side RBAC is a presentation and navigation layer. The server must authorize every protected operation and resource. Never present hidden UI as a security control.

## Model permissions

Prefer capability names over page names:

```ts
type Role = "admin" | "editor" | "viewer";
type Permission = "article.read" | "article.create" | "article.publish";

const rolePermissions: Record<Role, readonly Permission[]> = {
  admin: ["article.read", "article.create", "article.publish"],
  editor: ["article.read", "article.create"],
  viewer: ["article.read"],
};
```

Keep one policy source and expose small helpers such as `can(permission)` and `canAny(permissions)`.

## Workflow

1. Inventory protected actions and define permission vocabulary with the backend contract.
2. Map roles to permissions exhaustively.
3. Normalize the authenticated user's role and handle unknown or missing roles as denied.
4. Protect routes with a guard that distinguishes loading, unauthenticated, and unauthorized states.
5. Gate component actions through the same permission helper.
6. Choose hide versus disable intentionally. If disabled, explain why and how access can be obtained.
7. Keep deep links and browser navigation consistent with menu visibility.
8. Test each role, direct URL access, session changes, and denied API responses.

## Guardrails

- Do not scatter string comparisons such as `user.role === "admin"` across components.
- Do not infer permissions from UI labels.
- Do not flash protected content while authentication is loading.
- Do not redirect forever when user state is unresolved.
- Do not assume one role per user if the server contract supports multiple roles or direct grants.

When reviewing code, identify policy duplication, inconsistent guards, and missing server enforcement separately. When implementing, preserve the backend's deny-by-default behavior.