Com afegir control d'accés basat en rols (RBAC) a la teva app

Per afegir control d'accés basat en rols, dona a cada usuari un o més rols (per exemple administrador, editor o visualitzador), defineix quines accions pot fer cada rol i comprova aquests permisos al servidor a cada petició —no només amagant botons. A més, comprova que el registre al qual s'accedeix pertany al compte o a l'equip de l'usuari. Comença amb uns quants rols fixos a la teva base de dades i prova-ho intentant accedir directament a les dades d'un altre usuari.

Autenticació vs autorització

Dues paraules que es confonen sovint:

• Autenticació és qui ets? —iniciar sessió. Consulta com afegir inici de sessió a la teva app.
• Autorització és què pots fer? —a quines pàgines, registres i accions pot arribar un usuari que ha iniciat sessió.

El RBAC és la manera més habitual de fer autorització. És important: a partir del setembre de 2026, el Control d'accés trencat és el número 1 del OWASP Top 10:2025, la llista àmpliament usada dels riscos de seguretat més greus per a aplicacions web. Els fallos típics són usuaris que llegeixen els registres d'altres usuaris canviant un ID a la URL, o usuaris corrents que criden rutes d'API només per a administradors.

Triar un model

A la pràctica, la majoria d'apps combinen dues coses: els rols per al tipus d'accions que pot fer algú, i la propietat per als registres sobre els quals pot actuar. «Els editors poden editar entrades» és una regla de rol; «…entrades del seu propi espai de treball» és una regla de propietat. Necessites totes dues.

Comença més simple del que creus. Administrador, membre i visualitzador cobreixen un nombre sorprenent d'apps. És més fàcil dividir un rol més endavant que desfer el nus de deu rols que ningú entén.

Dissenya els rols abans d'escriure codi

Escriu primer una taula de permisos en llenguatge planer. Fa d'especificació per a la IA i també de pla de proves:

Decideix també els casos límit: pot marxar l'últim propietari? Pot un administrador eliminar el propietari? Què veu un usuari eliminat?

Pas a pas

1. Primer, tingues un inici de sessió que funcioni

El RBAC es basa en l'autenticació. El servidor ha de saber amb fiabilitat qui fa cada petició, a partir d'una sessió o d'un token verificat —mai a partir d'un ID d'usuari que el navegador envia al cos de la petició.

2. Guarda els rols a la base de dades

Per a una app d'un sol equip, una columna role a la taula d'usuaris és suficient. Per a equips, fes servir una taula de membresies:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

Mai no deixis que els usuaris establisquin el seu propi rol mitjançant una actualització normal del perfil. Els canvis de rol han de passar per un endpoint dedicat i amb comprovació de permisos.

3. Comprova els permisos al servidor, en un sol lloc

Escriu un sol ajudant —alguna cosa com can(user, 'projects.delete', project)— i crida'l a cada ruta d'API, acció de servidor i tasca en segon pla que llegeixi o canviï dades. Una funció central és més fàcil de revisar i de provar que les comprovacions dispersades pel codi. Denega per defecte: si cap regla permet una acció, es refusa.

4. Delimita cada consulta

Cada consulta de dades d'equip hauria d'incloure l'equip: where organization_id = :currentOrg, no només where id = :id. Això és el que impedeix que algú canviï /projects/123 per /projects/124 i vegi el projecte d'una altra empresa. Retorna «no trobat» en lloc de «prohibit» per als registres d'altres equips, per no revelar que existeixen.

5. Afegeix protecció a nivell de base de dades on importa

La seguretat a nivell de fila (RLS) de Postgres permet que la base de dades faci complir quines files pot veure cada usuari. És essencial si el navegador parla directament amb la base de dades (com passa amb alguns backends allotjats), i una segona capa útil per a les taules sensibles en la resta de casos.

6. Reflecteix els rols a la interfície

Ara amaga o desactiva el que els usuaris no poden fer, perquè l'app no resulti confusa. Això és només per a la usabilitat; les comprovacions del servidor són les que protegeixen.

7. Registra les accions sensibles

Registra qui ha canviat rols, ha eliminat dades o ha exportat registres, i quan. Un registre d'auditoria ajuda amb les preguntes de suport i els incidents.

8. Prova com un atacant

Inicia sessió com cada rol i prova totes les accions de la taula de permisos. Després prova les coses que no haurien de funcionar: cridar rutes d'API d'administrador com a visualitzador, canviar els IDs a les URL i a les peticions, eliminar-te com a últim propietari. Val la pena escriure proves automàtiques per a la taula de permisos quan les regles s'estabilitzin.

Indicacions que funcionen

Afegeix control d'accés basat en rols. Rols per organització: propietari, administrador, membre, visualitzador, guardats en una taula de membresies. Els permisos són en aquesta taula: [enganxa la teva taula]. Crea un sol ajudant al servidor can(user, action, resource), que denegui per defecte, i usa'l a cada ruta d'API. Delimita cada consulta per organization_id. Amaga a la interfície les accions que l'usuari no pot fer, però mai no hi confiïs per a la seguretat.

Revisa cada ruta d'API i funció de servidor d'aquesta app. Per a cadascuna, enumera quines dades llegeix o canvia, si comprova que l'usuari ha iniciat sessió, si comprova el seu rol i si delimita la consulta a la seva organització. Corregeix les que no tinguin una comprovació i mostra'm la llista.

Afegeix una pàgina /admin només per a administradors on el propietari pugui canviar els rols dels membres. Impedeix eliminar o degradar l'últim propietari, registra cada canvi de rol amb qui l'ha fet i quan, i assegura't que l'endpoint de canvi de rol rebutgi qualsevol que no sigui propietari.

Errors habituals

• Comprovar els rols només al frontend. L'API continua oberta a qualsevol que la cridi.
• Confiar en IDs del client: un userId o role al cos de la petició en lloc de la sessió.
• Consultes sense delimitar que obtenen registres només pel seu ID.
• Rols comprovats a les pàgines però no a les rutes d'API, exportacions, descàrregues de fitxers o webhooks.
• Administrador per adreça de correu codificada al codi (if email === 'me@...'), fàcil d'oblidar i difícil de canviar.
• Massa rols massa aviat, que ningú no sabrà explicar sis mesos després.
• Sessions obsoletes: un usuari degradat manté els drets d'administrador fins que tanca la sessió. Comprova els rols a la base de dades, o actualitza'ls, en accions sensibles.

Llista de comprovació del RBAC

• Taula de permisos escrita en llenguatge planer, casos límit decidits
• El servidor coneix l'usuari a partir de la sessió, mai a partir de dades de la petició
• Rols guardats a la base de dades; els usuaris no poden canviar els seus
• Una sola comprovació de permisos central, que denegui per defecte, usada a cada ruta
• Cada consulta delimitada a l'organització o propietat de l'usuari
• Seguretat a nivell de fila on el navegador pot arribar a la base de dades
• La interfície amaga el que els usuaris no poden fer (només per a la usabilitat)
• Accions sensibles registrades
• Cada rol provat, incloent les crides directes a l'API i els IDs canviats

El control d'accés és un punt d'una llista més llarga; la llista de comprovació de seguretat per a apps creades amb IA cobreix la resta. Si estàs construint una eina per al teu propi personal, com construir una eina interna mostra on encaixen els rols.

RBAC a Mythex

Mythex no ofereix un sistema d'inici de sessió ni de rols integrat per als usuaris de la teva app. Tu tries una biblioteca o un proveïdor d'autenticació i descrius els rols, i l'agent els connecta al teu codi i a la base de dades Postgres del projecte (afegir inici de sessió a la teva app). Els rols de l'espai de treball de Mythex, com Propietari i Membre, controlen qui pot editar els teus projectes de Mythex, no qui pot fer servir l'app que publiques. Fes servir el mode Pla per acordar la taula de permisos abans de construir, després usa la indicació de revisió de dalt i prova cada rol a la Vista prèvia abans de publicar. Les indicacions de seguretat de la documentació són un bon seguiment.

Preguntes