Cómo añadir control de acceso basado en roles (RBAC) a tu app

Para añadir control de acceso basado en roles, asigna a cada usuario uno o más roles (por ejemplo, administrador, editor, lector), define qué acciones puede realizar cada rol y comprueba esos permisos en el servidor en cada petición, no solo ocultando botones. Comprueba también que el registro al que se accede pertenece a la cuenta o al equipo del usuario. Empieza con unos pocos roles fijos en tu base de datos y prueba intentando acceder directamente a los datos de otro usuario.

Autenticación frente a autorización

Dos palabras que se confunden a menudo:

• Autenticación es ¿quién eres?: iniciar sesión. Consulta cómo añadir inicio de sesión a tu app.
• Autorización es ¿qué tienes permitido hacer?: a qué páginas, registros y acciones puede llegar un usuario con sesión iniciada.

RBAC es la forma más habitual de hacer autorización. Importa: a septiembre de 2026, el control de acceso roto ocupa el puesto nº 1 del OWASP Top 10:2025, la lista muy usada de los riesgos de seguridad más graves en aplicaciones web. Los fallos típicos son usuarios que leen los registros de otros cambiando un ID en la URL, o usuarios normales que llaman a rutas de API solo para administradores.

Elige un modelo

En la práctica, la mayoría de apps combinan dos cosas: roles para el tipo de acciones que alguien puede hacer, y propiedad para los registros sobre los que puede actuar. «Los editores pueden editar publicaciones» es una regla de rol; «…publicaciones de su propio espacio de trabajo» es una regla de propiedad. Necesitas ambas.

Empieza más simple de lo que crees. Administrador, miembro y lector cubren un número sorprendente de apps. Es más fácil dividir un rol más adelante que desenredar diez roles que nadie entiende.

Diseña los roles antes de escribir código

Escribe primero una tabla de permisos en lenguaje sencillo. Sirve como especificación para la IA y como plan de pruebas:

Decide también los casos límite: ¿puede salir el último propietario? ¿Puede un administrador quitar al propietario? ¿Qué ve un usuario eliminado?

Paso a paso

1. Ten primero un inicio de sesión que funcione

RBAC se apoya en la autenticación. El servidor debe saber con fiabilidad quién hace cada petición, a partir de una sesión o de un token verificado; nunca a partir de un ID de usuario que envíe el navegador en el cuerpo de la petición.

2. Guarda los roles en la base de datos

Para una app de un solo equipo, una columna role en los usuarios basta. Para equipos, usa una tabla de membresías:

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)
);

Nunca dejes que los usuarios cambien su propio rol mediante una actualización normal del perfil. Los cambios de rol deben pasar por un endpoint específico que compruebe permisos.

3. Comprueba los permisos en el servidor, en un solo lugar

Escribe una función auxiliar —algo como can(user, 'projects.delete', project)— y llámala en cada ruta de API, acción de servidor y tarea en segundo plano que lea o modifique datos. Una función central es más fácil de revisar y probar que comprobaciones repartidas por el código. Deniega por defecto: si ninguna regla permite una acción, se rechaza.

4. Limita cada consulta

Cada consulta de datos de equipo debe incluir el equipo: where organization_id = :currentOrg, no solo where id = :id. Esto es lo que impide que alguien cambie /projects/123 por /projects/124 y vea el proyecto de otra empresa. Devuelve «no encontrado» en lugar de «prohibido» para los registros de otros equipos, para no revelar que existen.

5. Añade protección a nivel de base de datos donde importa

La seguridad a nivel de fila (RLS) de Postgres permite que la base de datos imponga qué filas puede ver cada usuario. Es esencial si el navegador habla directamente con la base de datos (como en algunos backends alojados), y una segunda capa útil para las tablas sensibles en los demás casos.

6. Refleja los roles en la interfaz

Ahora oculta o desactiva lo que los usuarios no pueden hacer, para que la app no resulte confusa. Esto es solo para la usabilidad; las comprobaciones del servidor son las que protegen.

7. Registra las acciones sensibles

Anota quién cambió roles, eliminó datos o exportó registros, y cuándo. Un registro de auditoría ayuda con las consultas de soporte y con los incidentes.

8. Prueba como un atacante

Inicia sesión con cada rol y prueba cada acción de la tabla de permisos. Luego prueba lo que no debería funcionar: llamar a rutas de API de administración como lector, cambiar IDs en URLs y peticiones, quitarte a ti mismo como último propietario. Vale la pena escribir pruebas automáticas para la tabla de permisos cuando las reglas se estabilicen.

Prompts que funcionan

Añade control de acceso basado en roles. Roles por organización: propietario, administrador, miembro y lector, guardados en una tabla de membresías. Los permisos están en esta tabla: [pega tu tabla]. Crea una única función de servidor can(user, action, resource), que deniegue por defecto, y úsala en cada ruta de API. Limita cada consulta por organization_id. Oculta en la interfaz las acciones que el usuario no puede realizar, pero nunca confíes en eso para la seguridad.

Revisa cada ruta de API y cada función de servidor de esta app. Para cada una, lista qué datos lee o modifica, si comprueba que el usuario ha iniciado sesión, si comprueba su rol y si limita la consulta a su organización. Corrige las que no tengan alguna comprobación y muéstrame la lista.

Añade una página /admin solo para administradores donde el propietario pueda cambiar los roles de los miembros. Impide quitar o degradar al último propietario, registra cada cambio de rol con quién lo hizo y cuándo, y asegúrate de que el endpoint de cambio de rol rechace a cualquiera que no sea propietario.

Errores habituales

• Comprobar los roles solo en el frontend. La API sigue abierta para cualquiera que la llame.
• Confiar en los IDs del cliente: un userId o role en el cuerpo de la petición en lugar de en la sesión.
• Consultas sin limitar que buscan por ID de registro solamente.
• Roles comprobados en las páginas pero no en las rutas de API, exportaciones, descargas de archivos o webhooks.
• Administrador por dirección de correo fijada en el código (if email === 'yo@...'), fácil de olvidar y difícil de cambiar.
• Demasiados roles demasiado pronto, que nadie sabe explicar seis meses después.
• Sesiones obsoletas: un usuario degradado conserva derechos de administrador hasta que cierra sesión. Comprueba los roles en la base de datos, o refréscalos, en las acciones sensibles.

Lista de comprobación de RBAC

• Tabla de permisos escrita en lenguaje sencillo, con los casos límite decididos
• El servidor conoce al usuario por la sesión, nunca por datos de la petición
• Roles guardados en la base de datos; los usuarios no pueden cambiar los suyos
• Una única comprobación central de permisos, que deniega por defecto y se usa en todas las rutas
• Cada consulta limitada a la organización o propiedad del usuario
• Seguridad a nivel de fila donde el navegador pueda llegar a la base de datos
• La interfaz oculta lo que los usuarios no pueden hacer (solo por usabilidad)
• Acciones sensibles registradas
• Cada rol probado, incluidas las llamadas directas a la API y los IDs cambiados

El control de acceso es un punto de una lista más larga; la lista de seguridad para apps creadas con IA cubre el resto. Si construyes una herramienta para el personal de tu empresa, cómo crear una herramienta interna muestra dónde encajan los roles.

RBAC en Mythex

Mythex no ofrece un sistema integrado de inicio de sesión ni de roles para los usuarios de tu app. Tú eliges una librería de autenticación o un proveedor y describes los roles, y el agente los conecta a tu código y a la base de datos Postgres del proyecto (añadir inicio de sesión a tu app). Los roles de espacio de trabajo de Mythex, como Propietario y Miembro, controlan quién puede editar tus proyectos de Mythex, no quién puede usar la app que publicas. Usa el modo Plan para acordar la tabla de permisos antes de construir, y después usa el prompt de revisión de arriba y prueba cada rol en la vista previa antes de publicar. Los prompts de seguridad de la documentación son un buen siguiente paso.

Preguntas