Une API relie des applications et expose des op\u00e9rations sur des donn\u00e9es. Un utilisateur correctement authentifi\u00e9 ne doit pas pour autant pouvoir consulter ou modifier toutes les ressources disponibles.<\/p>\n\n\n
L\u2019OWASP d\u00e9crit le risque de contr\u00f4le d\u2019acc\u00e8s insuffisant au niveau des objets : le serveur re\u00e7oit un identifiant de ressource sans v\u00e9rifier correctement le droit de l\u2019utilisateur \u00e0 r\u00e9aliser l\u2019action demand\u00e9e. Des identifiants difficiles \u00e0 deviner ne remplacent pas cette v\u00e9rification.<\/p>\n\n\n
Pour chaque op\u00e9ration, pr\u00e9cisez quels r\u00f4les peuvent agir, sur quelles ressources et dans quel contexte. La lecture, la modification et la suppression peuvent demander des r\u00e8gles diff\u00e9rentes. Masquer un bouton dans l\u2019interface ne constitue pas un contr\u00f4le suffisant.<\/p>\n\n\n
Exemple fictif : un portail de documents comporte deux comptes de test appartenant \u00e0 deux clients distincts. Dans un environnement pr\u00e9vu pour l\u2019audit, v\u00e9rifiez que chaque compte ne peut lire et modifier que ses propres ressources. Les essais doivent rester dans le p\u00e9rim\u00e8tre autoris\u00e9.<\/p>\n\n\n
Ajoutez ces v\u00e9rifications aux tests de non-r\u00e9gression et documentez les exceptions m\u00e9tier. Les acc\u00e8s d\u00e9l\u00e9gu\u00e9s et les comptes de support demandent une attention particuli\u00e8re : leurs droits peuvent \u00eatre plus larges, mais doivent rester explicites. L\u2019objectif est de faire respecter la s\u00e9paration entre clients et entre fonctions \u00e0 chaque requ\u00eate, m\u00eame lorsque l\u2019utilisateur conna\u00eet l\u2019identifiant exact d\u2019une autre ressource.<\/p>\n\n\n