Comment ajouter le contrôle d'accès basé sur les rôles (RBAC) à votre application

Pour ajouter le contrôle d'accès basé sur les rôles, attribuez à chaque utilisateur un ou plusieurs rôles (par exemple administrateur, éditeur, lecteur), définissez les actions que chaque rôle peut effectuer, et vérifiez ces permissions sur le serveur pour chaque requête — pas seulement en masquant des boutons. Vérifiez aussi que l'enregistrement consulté appartient au compte ou à l'équipe de l'utilisateur. Commencez par quelques rôles fixes dans votre base de données, et testez en essayant d'atteindre directement les données d'un autre utilisateur.

Authentification ou autorisation

Deux termes qu'on confond souvent :

• L'authentification répond à qui êtes-vous? — la connexion. Voir comment ajouter une connexion à votre app.
• L'autorisation répond à qu'avez-vous le droit de faire? — les pages, les enregistrements et les actions auxquels un utilisateur connecté peut accéder.

Le RBAC est la façon la plus courante de réaliser l'autorisation. C'est important : en date de septembre 2026, le contrôle d'accès défaillant occupe le premier rang du Top 10 OWASP 2025, la liste largement utilisée des risques de sécurité les plus graves pour les applications web. Les défaillances typiques : des utilisateurs qui lisent les dossiers d'autres utilisateurs en modifiant un identifiant dans l'URL, ou des utilisateurs ordinaires qui appellent des routes d'API réservées aux administrateurs.

Choisir un modèle

Dans la pratique, la plupart des apps combinent deux éléments : des rôles pour le type d'actions qu'une personne peut poser, et la propriété pour les enregistrements sur lesquels elle peut agir. « Les éditeurs peuvent modifier les articles » est une règle de rôle; « ...les articles de leur propre espace de travail » est une règle de propriété. Vous avez besoin des deux.

Commencez plus simple que vous ne le pensez. Administrateur, membre et lecteur couvrent un nombre surprenant d'apps. Il est plus facile de diviser un rôle plus tard que de démêler dix rôles que personne ne comprend.

Concevoir les rôles avant d'écrire du code

Rédigez d'abord un tableau des permissions en langage clair. Il sert à la fois de spécification pour l'IA et de plan de test :

Décidez aussi des cas limites : le dernier propriétaire peut-il quitter? Un administrateur peut-il retirer le propriétaire? Que voit un utilisateur retiré?

Étape par étape

1. Avoir d'abord une connexion fonctionnelle

Le RBAC repose sur l'authentification. Le serveur doit savoir de façon fiable qui fait chaque requête, à partir d'une session ou d'un jeton vérifié — jamais à partir d'un identifiant d'utilisateur que le navigateur envoie dans le corps de la requête.

2. Stocker les rôles dans la base de données

Pour une app à une seule équipe, une colonne role dans la table des utilisateurs suffit. Pour les équipes, utilisez une table d'appartenances :

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

Ne laissez jamais les utilisateurs définir eux-mêmes leur rôle par une mise à jour ordinaire de leur profil. Les changements de rôle passent par un point de terminaison dédié, qui vérifie les permissions.

3. Vérifier les permissions sur le serveur, à un seul endroit

Écrivez une seule fonction d'aide — quelque chose comme can(user, 'projects.delete', project) — et appelez-la dans chaque route d'API, chaque action serveur et chaque tâche en arrière-plan qui lit ou modifie des données. Une fonction centrale est plus facile à examiner et à tester que des vérifications dispersées dans le code. Refusez par défaut : si aucune règle n'autorise une action, elle est refusée.

4. Limiter chaque requête

Chaque requête portant sur les données d'équipe doit inclure l'équipe : where organization_id = :currentOrg, et non seulement where id = :id. C'est ce qui empêche quelqu'un de changer /projects/123 en /projects/124 et de voir le projet d'une autre entreprise. Renvoyez « introuvable » plutôt que « interdit » pour les enregistrements d'autres équipes, afin de ne pas révéler leur existence.

5. Ajouter une protection au niveau de la base de données là où elle compte

La sécurité au niveau des lignes (RLS) de Postgres permet à la base de données d'imposer les lignes que chaque utilisateur peut voir. Elle est essentielle si le navigateur communique directement avec la base de données (comme dans certains backends hébergés), et constitue une deuxième couche utile pour les tables sensibles dans les autres cas.

6. Refléter les rôles dans l'interface

Masquez ou désactivez maintenant ce que les utilisateurs ne peuvent pas faire, afin que l'app ne soit pas confuse. Cela ne sert qu'à l'utilisabilité; ce sont les vérifications côté serveur qui protègent réellement.

7. Journaliser les actions sensibles

Consignez qui a modifié des rôles, supprimé des données ou exporté des enregistrements, et quand. Un journal d'audit aide à répondre aux questions du soutien et à gérer les incidents.

8. Tester comme un attaquant

Connectez-vous avec chaque rôle et essayez chaque action du tableau des permissions. Puis essayez ce qui ne devrait pas fonctionner : appeler des routes d'API d'administration en tant que lecteur, modifier les identifiants dans les URL et les requêtes, vous retirer comme dernier propriétaire. Des tests automatisés pour le tableau des permissions valent la peine d'être écrits une fois les règles stabilisées.

Requêtes qui fonctionnent

Ajoute le contrôle d'accès basé sur les rôles. Rôles par organisation : propriétaire, administrateur, membre, lecteur, stockés dans une table memberships. Les permissions sont dans ce tableau : [colle ton tableau]. Crée une seule fonction serveur can(user, action, resource), qui refuse par défaut, et utilise-la dans chaque route d'API. Limite chaque requête par organization_id. Masque dans l'interface les actions que l'utilisateur ne peut pas effectuer, mais ne te fie jamais à cela pour la sécurité.

Passe en revue chaque route d'API et chaque fonction serveur de cette app. Pour chacune, indique quelles données elle lit ou modifie, si elle vérifie que l'utilisateur est connecté, si elle vérifie son rôle, et si elle limite la requête à son organisation. Corrige celles qui n'ont pas une vérification, et montre-moi la liste.

Ajoute une page /admin réservée aux administrateurs, où le propriétaire peut modifier les rôles des membres. Empêche de retirer ou de rétrograder le dernier propriétaire, journalise chaque changement de rôle avec son auteur et la date, et assure-toi que le point de terminaison de changement de rôle refuse toute personne qui n'est pas propriétaire.

Erreurs courantes

• Vérifier les rôles uniquement dans l'interface. L'API reste ouverte à quiconque l'appelle.
• Faire confiance aux identifiants venant du client — un userId ou un role dans le corps de la requête au lieu de la session.
• Des requêtes non limitées qui recherchent un enregistrement uniquement par son identifiant.
• Vérifier les rôles sur les pages, mais pas sur les routes d'API, les exportations, les téléchargements de fichiers ou les webhooks.
• Un administrateur désigné par adresse courriel codée en dur dans le code (if email === 'moi@...'), facile à oublier et difficile à modifier.
• Trop de rôles, trop tôt, que personne ne peut expliquer six mois plus tard.
• Des sessions périmées : un utilisateur rétrogradé conserve ses droits d'administrateur jusqu'à sa déconnexion. Vérifiez les rôles dans la base de données, ou actualisez-les, pour les actions sensibles.

Liste de contrôle du RBAC

• Tableau des permissions rédigé en langage clair, cas limites décidés
• Le serveur connaît l'utilisateur grâce à la session, jamais à partir des données de la requête
• Rôles stockés dans la base de données; les utilisateurs ne peuvent pas modifier les leurs
• Une seule vérification centrale des permissions, qui refuse par défaut, utilisée dans chaque route
• Chaque requête limitée à l'organisation ou à la propriété de l'utilisateur
• Sécurité au niveau des lignes là où le navigateur peut atteindre la base de données
• L'interface masque ce que les utilisateurs ne peuvent pas faire (pour l'utilisabilité seulement)
• Actions sensibles journalisées
• Chaque rôle testé, y compris les appels directs à l'API et les identifiants modifiés

Le contrôle d'accès n'est qu'un point d'une liste plus longue; la liste de contrôle de sécurité pour les apps créées avec l'IA couvre le reste. Si vous créez un outil pour votre personnel, comment créer un outil interne montre où les rôles s'insèrent.

Le RBAC sur Mythex

Mythex ne fournit pas de système intégré de connexion ou de rôles pour les utilisateurs de votre app. Vous choisissez une bibliothèque ou un fournisseur d'authentification et décrivez les rôles; l'agent les intègre dans votre code et dans la base de données Postgres du projet (ajouter une connexion à votre app). Les rôles de l'espace de travail Mythex, comme Propriétaire et Membre, contrôlent qui peut modifier vos projets Mythex, et non qui peut utiliser l'app que vous publiez. Utilisez le mode Plan pour convenir du tableau des permissions avant de créer, puis utilisez la requête de révision ci-dessus et testez chaque rôle dans l'aperçu avant de publier. Les requêtes de sécurité de la documentation sont un bon complément.

Questions