Réponse.

Le test manuel des droits d'accès et des rôles permet de vérifier que différents types d'utilisateurs ont le niveau d'accès approprié aux fonctionnalités et aux données de l'application.

Contexte de la question

Avec l'augmentation du nombre d'utilisateurs et de leurs scénarios d'utilisation, même les applications simples ont adopté un modèle de rôles. Des erreurs de droits ont souvent conduit à de graves fuites de données ou à des restrictions des opérations commerciales. D'où la nécessité de tester manuellement les rôles de manière approfondie.

Problèmes

négligence des erreurs dans la restriction d'accès aux données sensibles ;
mauvaise configuration des rôles, permettant aux utilisateurs d'effectuer des actions non autorisées (par exemple, accès aux fonctions administratives pour les utilisateurs ordinaires) ;
difficultés à vérifier les rôles combinés ou les scénarios d'accès non standard.

Solutions

Documenter tous les rôles existants et les actions correspondantes pour chaque rôle ;
Créer des ensembles de tests pour chaque rôle, y compris des intersections conditionnelles de rôles ;
Vérifier l'accès non seulement aux fonctionnalités, mais aussi à différentes parties des données (CRUD) ;
Valider à la fois l'accès direct (via l'UI) et les tentatives d'accès via des liens directs ou des API.

Caractéristiques clés :

Couverture complète des scénarios : chaque type d'utilisateur doit être vérifié dans tous les rôles et actions possibles ;
Test des rôles limites et combinés : les erreurs apparaissent souvent lors du chevauchement des droits de différents rôles ;
Vérification du contournement des interfaces standard : test d'accès direct aux pages/actions auxquelles l'utilisateur n'a officiellement pas de droits.

Questions pièges.

Est-il suffisant de tester uniquement les rôles principaux (par exemple, "Administrateur" et "Utilisateur") ?

Non. C'est souvent dans les rôles intermédiaires, peu utilisés et combinés que se cachent les défauts.

La limitation de l'UI (boutons et éléments cachés) est-elle suffisante pour la sécurité ?

Non. Le contrôle de l'UI ne protège pas contre les tentatives d'accès direct via l'adresse ou l'API, les droits doivent être restreints au niveau de la logique serveur.

Faut-il tester les droits d'accès via différents canaux de l'application (par exemple, à la fois sur le web et via l'application mobile) ?

Obligatoire. Souvent, les différences dans la mise en œuvre entraînent des variations de comportement et des erreurs dans les restrictions de droits.

Erreurs typiques et anti-modèles

Vérification uniquement des rôles standard
Focalisation uniquement sur l'interface externe, sans validation des restrictions serveur
Négligence des rôles non standards et combinés

Exemple de la vie réelle

Cas négatif

Seule l'UI a été vérifiée et uniquement trois rôles principaux. En conséquence, des utilisateurs avec une combinaison non standard de rôles ont pu accéder à des fonctions administratives via un lien direct.

Avantages :

Test rapide
Simplicité du processus

Inconvénients :

Vulnérabilité critique détectée en production
Violation de la sécurité et de la confiance des utilisateurs

Cas positif

Des utilisateurs de test avec diverses combinaisons de rôles ont été créés pour le test, un audit de l'API et de l'accès direct a été réalisé. Les erreurs ont été trouvées et corrigées avant la sortie.