Gérer les droits d’accès : rôles, permissions et moindre privilège

Gérer les droits d’accès d’une application, c’est décider qui peut voir quoi et faire quoi, puis le vérifier à chaque action. La méthode qui fonctionne repose sur trois éléments : des rôles peu nombreux qui décrivent les métiers, un périmètre qui limite les données visibles (agence, client, dossier) et le principe du moindre privilège, qui consiste à n’accorder que le strict nécessaire. Le tout doit être contrôlé côté serveur, documenté dans une matrice des droits et revu au moins une fois par an.

Ce sujet paraît technique. Il est en réalité organisationnel : ce sont les responsables métier qui savent qui doit accéder à quoi. Le rôle de l’équipe de développement est de traduire ces règles sans faille.

Pourquoi le contrôle d’accès est-il la première faille des applications web ?

Le classement de référence de l’OWASP, qui recense les risques de sécurité les plus critiques des applications web, place le contrôle d’accès défaillant en première position de son édition 2025. Selon la page OWASP consacrée à cette catégorie, 100 % des applications testées présentaient au moins une forme de contrôle d’accès défaillant, avec 40 faiblesses types (CWE) rattachées à cette catégorie.

La raison est simple : contrairement à une injection SQL, une faille de droits n’est pas un défaut de programmation générique qu’un outil détecte seul. C’est une règle métier oubliée. Un exemple typique : la page « détail d’une commande » vérifie que l’utilisateur est connecté, mais pas que la commande appartient bien à son entreprise. Il suffit alors de modifier le numéro dans l’adresse pour consulter la commande d’un concurrent.

Les conséquences sont lourdes pour une PME ou une ETI : fuite de données clients, violation de données personnelles à notifier, perte de confiance d’un donneur d’ordre. C’est pourquoi ce point fait partie des risques détaillés dans notre article sur l’OWASP Top 10 expliqué aux dirigeants.

Rôles, permissions, périmètre : les notions à distinguer

Trois notions se mélangent souvent dans les cahiers des charges. Les séparer clarifie tout le reste.

• Une permission est une action élémentaire sur un type d’objet : « créer un devis », « valider une note de frais », « exporter la liste des clients ».
• Un rôle est un regroupement nommé de permissions qui correspond à un métier : commercial, responsable d’agence, comptable, administrateur.
• Un périmètre limite les données sur lesquelles s’exercent ces permissions : son agence, ses clients, les dossiers qui lui sont affectés.

Le modèle de contrôle d’accès par rôles, appelé RBAC (Role-Based Access Control), a été formalisé par le NIST. Il est simple à expliquer et à auditer. Sa limite, soulignée par la fiche OWASP sur l’autorisation, est qu’il gère mal les décisions qui dépendent de l’objet lui-même. Pour cela, on complète les rôles par des règles fondées sur des attributs (ABAC : l’agence de l’utilisateur, le statut du dossier, l’heure) ou sur des relations (ReBAC : l’utilisateur est le créateur du dossier, ou membre de l’équipe projet).

Dans la pratique, une application métier bien conçue utilise les rôles pour les fonctionnalités et le périmètre pour les données. Ce duo couvre l’essentiel des besoins sans complexité inutile.

Le moindre privilège, concrètement

Le principe du moindre privilège consiste à accorder à chaque personne les seuls droits nécessaires à sa mission, pour la durée nécessaire. La CNIL le présente comme le moyen de limiter les dégâts en cas d’usurpation de compte ou d’erreur de manipulation : un compte compromis n’expose que ce qu’il pouvait voir.

Il se traduit par des choix très concrets dans l’application :

1. Interdire par défaut. Toute fonctionnalité nouvelle est fermée à tous tant qu’un rôle n’a pas été explicitement autorisé.
2. Séparer les tâches. Celui qui crée un fournisseur n’est pas celui qui valide son RIB ; celui qui saisit une dépense n’est pas celui qui l’approuve. C’est le cœur des circuits de validation.
3. Limiter les comptes administrateurs. Deux ou trois personnes nommément désignées, avec une authentification forte, plutôt qu’un compte « admin » partagé.
4. Donner des accès temporaires datés. Un remplacement de congé ou un audit externe reçoit des droits qui expirent automatiquement.
5. Masquer ce qui n’est pas utile. Un technicien terrain n’a pas besoin de voir la marge d’une affaire, même en lecture seule.

Construire la matrice des droits pendant le cadrage

La matrice des droits est un tableau qui croise les rôles et les actions, en précisant le périmètre. Elle se rédige avec les métiers pendant la phase de cadrage, pas à la fin du développement. Prenons une entreprise hypothétique de maintenance multi-agences :

Ce tableau sert trois fois : il guide le développement, il devient le plan de test de la recette, et il sert de support à la revue annuelle des habilitations. Il gagne à figurer dans votre cahier des charges.

Deux questions à poser systématiquement en atelier : « que se passe-t-il quand quelqu’un change d’agence ? » et « qui a le droit de donner des droits ? ». Les réponses révèlent souvent des règles implicites que personne n’avait formulées.

Les règles techniques à exiger de votre prestataire

Vous n’avez pas à connaître le code pour vérifier que les bonnes pratiques sont appliquées. Voici ce que l’OWASP recommande et ce que vous pouvez demander.

• Un contrôle côté serveur, à chaque requête. Masquer un bouton dans l’interface ne protège rien : la vérification doit avoir lieu sur le serveur, pour chaque appel, y compris dans les API utilisées par une application mobile.
• Un mécanisme centralisé. Les règles de droits sont écrites une fois, dans un module commun, puis réutilisées partout. Les contrôles dispersés page par page finissent toujours par en oublier une.
• La vérification de propriété de chaque objet. Pour chaque dossier, facture ou document demandé, l’application vérifie qu’il appartient au périmètre de l’utilisateur. Rendre les identifiants difficiles à deviner ne suffit pas.
• Les fichiers aussi. Les pièces jointes et documents stockés dans le cloud obéissent aux mêmes règles que les écrans.
• Des tests automatisés des droits. Pour chaque ligne de la matrice, un test vérifie qu’un rôle autorisé passe et qu’un rôle non autorisé est refusé. C’est l’un des meilleurs investissements décrits dans notre article sur les tests automatisés.
• La journalisation des refus. Une série de refus d’accès sur un même compte est un signal d’alerte. Le sujet est détaillé dans notre article sur la journalisation et la traçabilité.

Dans un SaaS ou un portail client, une règle s’ajoute : l’isolation entre clients doit être garantie à la racine, pas seulement écran par écran. C’est l’un des enjeux de l’architecture multi-tenant.

Le cycle de vie des habilitations : arrivée, mobilité, départ

Un modèle de droits parfait se dégrade avec le temps si personne ne l’entretient. Les droits s’accumulent au fil des changements de poste : c’est ce que l’OWASP appelle la dérive des privilèges. La CNIL liste les erreurs les plus fréquentes : comptes partagés non tracés, droits d’administrateur accordés par confort, autorisations temporaires jamais retirées, comptes de personnes parties toujours actifs.

Pour les éviter, l’application doit outiller le processus :

1. Arrivée : une demande d’habilitation validée par un responsable, tracée avec sa date et son auteur.
2. Mobilité : le changement de rôle retire les anciens droits au lieu d’ajouter les nouveaux.
3. Départ : la désactivation est immédiate. Avec une authentification unique (SSO), désactiver le compte dans l’annuaire de l’entreprise coupe l’accès à toutes les applications reliées.
4. Revue annuelle : la CNIL recommande une revue des habilitations au minimum annuelle, à laquelle les métiers participent. Un export « qui a accès à quoi » par service rend l’exercice réaliste en une demi-journée.

L’authentification forte (MFA, passkeys) complète ce dispositif pour les comptes sensibles, à commencer par les administrateurs.

Les erreurs de conception qui coûtent cher

Certaines erreurs reviennent dans les audits d’applications métier, quel que soit le secteur.

• Le rôle « super utilisateur » donné à tous les chefs de service pour « débloquer » les situations. Il devient la norme, et le moindre privilège disparaît.
• Des rôles nommés d’après des personnes (« rôle Sophie ») plutôt que d’après des fonctions. Au premier départ, plus personne ne sait ce qu’il autorise.
• Un modèle de droits ajouté après coup. Si l’application a été construite sans notion de périmètre, ajouter « seulement son agence » impose de reprendre chaque écran et chaque requête. C’est une forme coûteuse de dette technique.
• Des exports sans contrôle. L’écran est protégé, mais l’export Excel renvoie toute la base.
• Aucune trace des modifications de droits. En cas d’incident, impossible de savoir qui a accordé l’accès et quand.

Par où commencer ?

Si vous préparez une nouvelle application, faites de la matrice des droits un livrable du cadrage et exigez des tests automatisés pour chacune de ses lignes. Si votre application existe déjà, commencez par un inventaire : liste des rôles, nombre de comptes administrateurs, comptes inactifs depuis plus de six mois, accès des personnes parties. Cet état des lieux prend peu de temps et révèle souvent l’essentiel des risques.

Le sujet rejoint vos obligations au titre du RGPD : limiter l’accès aux données personnelles à ceux qui en ont besoin fait partie des mesures de sécurité attendues. Vous voulez faire le point sur les droits d’accès d’une application existante ou en concevoir une nouvelle sur des bases saines ? Décrivez votre contexte dans notre diagnostic de projet.