Broken Access Control : le contrôle d'accès défaillant
C'est le risque n°1 du Top 10 de l'OWASP. Un contrôle d'accès défaillant permet à un utilisateur d'accéder à des données ou d'effectuer des actions qui ne devraient pas lui être permises. Un classique aux conséquences souvent lourdes.
OWASP Top 10 : de quoi parle-t-on ?
L'OWASP (Open Web Application Security Project) est une communauté de référence pour la sécurité applicative. Son Top 10 classe les dix risques les plus critiques pour les applications web, actualisé au fil des versions. Depuis 2021, le contrôle d'accès défaillant y figure en première position.
Le contrôle d'accès, c'est ce qui garantit que chacun ne peut faire que ce qui lui est autorisé. Quand il est mal conçu ou incomplet, un utilisateur peut consulter les données d'autrui, accéder à des fonctions d'administration ou modifier des ressources qui ne lui appartiennent pas. Un sujet au cœur de la sécurité applicative.
Les formes courantes
Référence directe non sécurisée
Modifier un identifiant dans l'URL (« id=123 » → « id=124 ») pour accéder aux données d'un autre utilisateur. Le grand classique de l'IDOR.
Élévation de privilèges
Accéder à des fonctions réservées aux administrateurs faute de vérification côté serveur des droits réels de l'utilisateur.
Accès direct aux URL
Atteindre une page « cachée » en devinant son adresse, alors qu'aucun contrôle n'en restreint réellement l'accès.
API mal protégées
Des points d'accès API qui ne vérifient pas les autorisations, exposant des données ou des actions sensibles.
Pourquoi est-ce si fréquent ?
Le contrôle d'accès est transversal : il doit être vérifié à chaque requête, sur chaque ressource, côté serveur. Or il est tentant de se reposer sur l'interface (masquer un bouton ne protège rien) ou d'oublier un point d'accès. Une seule vérification manquante suffit. Les conséquences vont de la fuite de données au vol de compte, surtout si un compte à privilèges est atteint.
Le principe : « refuser par défaut », vérifier côté serveur
Un bon contrôle d'accès repose sur quelques principes solides : tout refuser par défaut et n'autoriser qu'explicitement, vérifier les droits côté serveur à chaque requête (jamais uniquement dans l'interface), appliquer le moindre privilège, et ne jamais se fier à un identifiant fourni par le client sans contrôle de propriété. Ces vérifications se valident concrètement par un test d'intrusion.
Se protéger, étape par étape
Refuser par défaut
Partir d'un accès fermé et n'ouvrir qu'explicitement, ressource par ressource.
Vérifier côté serveur
Contrôler les droits à chaque requête sur le serveur, jamais seulement dans l'interface utilisateur.
Contrôler la propriété
Vérifier que l'utilisateur a bien le droit d'accéder à la ressource demandée, et pas seulement qu'il est connecté.
Appliquer le moindre privilège
Limiter les droits de chaque rôle au strict nécessaire, et revoir régulièrement les habilitations.
Journaliser les accès
Tracer les accès sensibles et les refus pour détecter les tentatives d'abus.
Pourquoi se faire accompagner par BCIT ?
Des tests par rôle
Nous éprouvons les accès depuis différents profils pour révéler les failles de contrôle réelles.
Des correctifs clairs
Des recommandations directement applicables par vos développeurs, priorisées par impact.
Une vision d'ensemble
De la sécurité applicative aux audits, toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Vos utilisateurs n'accèdent-ils qu'à ce qui les concerne ?
Prenons 15 minutes pour évaluer la robustesse de vos contrôles d'accès et définir les priorités de correction.
Broken Access Control : le contrôle d'accès défaillant
C'est le risque n°1 du Top 10 de l'OWASP. Un contrôle d'accès défaillant permet à un utilisateur d'accéder à des données ou d'effectuer des actions qui ne devraient pas lui être permises. Un classique aux conséquences souvent lourdes.
OWASP Top 10 : de quoi parle-t-on ?
L'OWASP (Open Web Application Security Project) est une communauté de référence pour la sécurité applicative. Son Top 10 classe les dix risques les plus critiques pour les applications web, actualisé au fil des versions. Depuis 2021, le contrôle d'accès défaillant y figure en première position.
Le contrôle d'accès, c'est ce qui garantit que chacun ne peut faire que ce qui lui est autorisé. Quand il est mal conçu ou incomplet, un utilisateur peut consulter les données d'autrui, accéder à des fonctions d'administration ou modifier des ressources qui ne lui appartiennent pas. Un sujet au cœur de la sécurité applicative.
Les formes courantes
Référence directe non sécurisée
Modifier un identifiant dans l'URL (« id=123 » → « id=124 ») pour accéder aux données d'un autre utilisateur. Le grand classique de l'IDOR.
Élévation de privilèges
Accéder à des fonctions réservées aux administrateurs faute de vérification côté serveur des droits réels de l'utilisateur.
Accès direct aux URL
Atteindre une page « cachée » en devinant son adresse, alors qu'aucun contrôle n'en restreint réellement l'accès.
API mal protégées
Des points d'accès API qui ne vérifient pas les autorisations, exposant des données ou des actions sensibles.
Pourquoi est-ce si fréquent ?
Le contrôle d'accès est transversal : il doit être vérifié à chaque requête, sur chaque ressource, côté serveur. Or il est tentant de se reposer sur l'interface (masquer un bouton ne protège rien) ou d'oublier un point d'accès. Une seule vérification manquante suffit. Les conséquences vont de la fuite de données au vol de compte, surtout si un compte à privilèges est atteint.
Le principe : « refuser par défaut », vérifier côté serveur
Un bon contrôle d'accès repose sur quelques principes solides : tout refuser par défaut et n'autoriser qu'explicitement, vérifier les droits côté serveur à chaque requête (jamais uniquement dans l'interface), appliquer le moindre privilège, et ne jamais se fier à un identifiant fourni par le client sans contrôle de propriété. Ces vérifications se valident concrètement par un test d'intrusion.
Se protéger, étape par étape
Refuser par défaut
Partir d'un accès fermé et n'ouvrir qu'explicitement, ressource par ressource.
Vérifier côté serveur
Contrôler les droits à chaque requête sur le serveur, jamais seulement dans l'interface utilisateur.
Contrôler la propriété
Vérifier que l'utilisateur a bien le droit d'accéder à la ressource demandée, et pas seulement qu'il est connecté.
Appliquer le moindre privilège
Limiter les droits de chaque rôle au strict nécessaire, et revoir régulièrement les habilitations.
Journaliser les accès
Tracer les accès sensibles et les refus pour détecter les tentatives d'abus.
Pourquoi se faire accompagner par BCIT ?
Des tests par rôle
Nous éprouvons les accès depuis différents profils pour révéler les failles de contrôle réelles.
Des correctifs clairs
Des recommandations directement applicables par vos développeurs, priorisées par impact.
Une vision d'ensemble
De la sécurité applicative aux audits, toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Vos utilisateurs n'accèdent-ils qu'à ce qui les concerne ?
Prenons 15 minutes pour évaluer la robustesse de vos contrôles d'accès et définir les priorités de correction.