Audit d'authentification et de permissions, qui peut faire quoi.
Un audit d'authentification et de permissions vérifie que chaque compte n'accède qu'à ses propres données et à ses propres actions, jamais à celles d'un autre utilisateur, d'un administrateur ou d'une autre entreprise cliente. Nos outils maison croisent chaque action avec chaque compte, et notre expertise manuelle repère les accès que personne n'avait prévu de donner.
En bref
- Le périmètreApplications web, espaces clients, back-offices et API, dès qu'il existe plusieurs rôles.
- Ce que nous cherchonsL'accès horizontal entre comptes, l'élévation verticale, le cloisonnement entre entreprises clientes, les sessions et les jetons.
- Ce qu'il nous fautDeux comptes par niveau, et deux entreprises clientes distinctes si votre plateforme en accueille plusieurs.
- Ce que vous recevezUn rapport avec votre matrice de droits testée et la preuve de chaque faille, une restitution avec votre équipe et un retest sous 60 jours.
Vulnérabilités trouvées dans ces secteurs
- Services publics (.gouv.fr)
- Groupes du CAC 40
- Leaders du luxe
- Médias nationaux
- Mairies et collectivités
Une injection se voit. Un accès de trop, jamais.
L'attaquant se connecte avec son vrai compte, appelle une adresse légitime et remplace un numéro par un autre. Du point de vue du serveur, tout est en ordre.
C'est pour cette raison que ces failles survivent aux outils, aux pare-feux applicatifs et souvent aux revues de code. Le code fait exactement ce qu'on lui demande : il renvoie la fiche demandée. Ce qui manque, c'est la ligne qui vérifie qu'elle appartient bien à la personne qui la demande, oubliée surtout là où une fonctionnalité a été ajoutée dans l'urgence.
Le risque grandit avec le succès du produit. Une application démarre avec deux rôles et une poignée d'écrans. Trois ans plus tard, elle en a sept, des exceptions, une API mobile et un back-office interne. Personne ne détient plus la matrice complète, et c'est dans ses trous que se logent les problèmes.
L'attaquant n'a même pas besoin d'un accès privilégié pour commencer : un compte ordinaire suffit, parfois récupéré dans une fuite de données. Ce qu'un compte ordinaire atteint, c'est exactement ce que cette prestation mesure.
Avant le correctif
Un membre de l'entreprise 12 liste les membres de l'entreprise 13 : un autre client de la plateforme.
Après le correctif
Le serveur vérifie l'entreprise du compte à chaque appel : la 13 lui est refusée.
Le même compte, l'entreprise d'à côté. Retournez la carte pour voir la correction.
Quand auditer vos accès.
Les droits d'une application ne restent jamais tels qu'on les a pensés : chaque rôle, chaque client et chaque nouvelle porte les déplacent.
Avant d'ajouter un rôle
Un nouveau rôle croise tous les autres : chaque droit existant mérite d'être revérifié.
Avant d'accueillir de gros clients
Plusieurs entreprises clientes sur la même plateforme : leur cloisonnement devient votre promesse principale.
Au lancement d'une application mobile
Une deuxième porte vers les mêmes données, qui refait souvent ses propres vérifications.
Après un passage au SSO
Changer la façon d'entrer ne change pas ce qu'on peut faire une fois entré : les deux se vérifient.
Une fois par an
Les rôles s'empilent, les exceptions aussi, et la matrice devient difficile à suivre.
Ce que nous franchissons.
Six frontières que votre application est censée tenir. Notre travail consiste à essayer de passer, méthodiquement.
Accès horizontal
Atteindre les données d'un autre compte du même niveau en changeant un identifiant, un lien de partage ou un numéro de document : une Une référence directe à un objet, mal protégée : changer un numéro dans une requête suffit à atteindre la donnée d'un autre..
Élévation verticale
Obtenir depuis un compte standard une action réservée à un administrateur, en appelant la fonction que l'interface se contente de masquer.
Cloisonnement entre entreprises
Franchir la frontière entre deux clients d'une même plateforme, l'un des défauts les plus coûteux d'un produit SaaS.
Interface, API et mobile
Une règle appliquée à l'écran mais absente de l'appel qui se trouve derrière, ou présente sur le web et oubliée sur l'application mobile.
Sessions et jetons
Expiration réelle, déconnexion, changement de mot de passe, sessions parallèles, et Le badge numérique qu'un compte reçoit à la connexion : tant qu'il reste valide, il ouvre les portes sans redemander le mot de passe. qui survivent à leur révocation.
Reprise de compte et second facteur
Mot de passe oublié, changement d'adresse, liens d'invitation, et les chemins où le second facteur n'est jamais demandé.
Comment se déroule un audit des accès.
Six étapes, du modèle de droits au retest, pour vérifier chaque case de la matrice.
Lire la méthodologie complète- 01
Modèle de droits
On écrit ensemble ce que chaque rôle est censé pouvoir faire. Beaucoup de clients découvrent à cette étape que ce document n'existe nulle part, ou qu'il ne correspond plus à l'application. C'est déjà un résultat : on ne défend pas une frontière qu'on n'a pas tracée.
- 02
Comptes et données
Nous créons, ou vous nous fournissez, les comptes nécessaires, avec des données propres à chacun : documents, commandes, messages. Sans données distinctes, impossible de prouver qu'une frontière a été franchie.
- 03
Inventaire des actions
Nous parcourons l'application avec le compte le plus privilégié et relevons chaque action qui lit ou modifie quelque chose d'important. Cet inventaire devient la liste des cas à rejouer.
- 04
Franchissement
Chaque action est rejouée avec chaque rôle, puis avec les identifiants d'un autre compte, puis d'une autre entreprise. Nos outils maison prennent en charge la répétition, et l'expertise manuelle juge chaque réponse, ce qu'un scanner ne sait pas faire seul.
- 05
Chaînage
Un accès isolé vaut peu, un enchaînement vaut cher. Nous vérifions ce qu'on atteint en partant d'une seule brèche, et jusqu'où descend la chaîne.
- 06
Rapport et retest
Vous recevez la matrice avec ce qui tient et ce qui cède, chaque franchissement avec sa requête et sa preuve, et le correctif attendu. Après vos corrections, nous rejouons l'ensemble des cas concernés. Voir un exemple de rapport.
Boîte noire, grise ou blanche.
Ce que vous nous donnez au départ décide de ce que l'audit peut atteindre. Ici, presque tout se joue une fois connecté : notre conseil, des comptes à chaque niveau.
Boîte noire : l'adresse seule
- Vous fournissez
- L'adresse de l'application, sans aucun compte.
- Le test atteint
- La connexion, l'inscription et la reprise de compte, vues de l'extérieur. Les permissions elles-mêmes restent hors d'atteinte.
- À choisir quand
- Rarement pour cette mission, qui porte sur ce qui se passe une fois connecté.
Boîte grise : des comptes à chaque niveau Notre conseil
- Vous fournissez
- Deux comptes par niveau, et deux entreprises clientes distinctes si votre plateforme en accueille plusieurs.
- Le test atteint
- Toute la matrice : chaque action rejouée avec chaque rôle, puis avec les identifiants d'un autre compte et d'une autre entreprise.
- À choisir quand
- Presque toujours : c'est la configuration pour laquelle cette mission est faite.
Boîte blanche : les comptes et le code
- Vous fournissez
- Les comptes, plus un accès en lecture au code qui décide des droits.
- Le test atteint
- Aussi les vérifications manquantes que l'interface ne permet pas d'atteindre, lues directement dans le code.
- À choisir quand
- Quand le modèle de droits est complexe, ou réparti entre plusieurs services.
Ce que ça donne en pratique.
Des failles réelles trouvées dans des contrôles d'accès, toutes corrigées depuis.
rapports envoyés avec une vulnérabilité critique
Sur plus de 485 rapports envoyés, en test d'intrusion et en bug bounty.
rapports envoyés au total
En test d'intrusion et en bug bounty.
Actifs en bug bounty
Chercheurs sur YesWeHack et Intigriti, deux plateformes européennes où chaque faille est vérifiée avant d'être acceptée.
- CritiqueCorrigée
IDOR
Téléchargement des factures de n'importe quel client en incrémentant un numéro de document.
- CritiqueCorrigée
Cloisonnement
Utilisateur d'une entreprise capable de lister les membres et les projets d'une autre entreprise.
- CritiqueCorrigée
Élévation verticale
Route d'administration appelable directement par un compte standard, le contrôle n'existant que dans l'interface.
- ÉlevéeCorrigée
Reprise de compte
Jeton de réinitialisation prévisible, permettant de prendre la main sur un compte à partir de sa seule adresse.
Nous ne divulguons jamais le nom d'un client, ni aucun détail qui permettrait de le reconnaître.
Le rapport que vous recevez.
Chaque franchissement prouvé, expliqué et rattaché à la vérification qui manque : lisible par votre direction, applicable par vos développeurs.
Les factures de tous les clients, téléchargeables depuis n'importe quel compte en changeant un numéro de document.
GravitéCritique, depuis un compte client
Requêtes, captures et étapes de reproduction : caviardées dans cet exemple. Votre rapport contient chacune d'elles, prête à rejouer.
Vérifier à chaque téléchargement que le document appartient au compte qui le demande, et refuser par défaut.
PrioritéImmédiate, retest inclus
Les membres et les projets d'une autre entreprise, visibles depuis un compte ordinaire : la promesse de cloisonnement de la plateforme, rompue.
GravitéCritique, d'une entreprise à l'autre
Requêtes, captures et étapes de reproduction : caviardées dans cet exemple. Votre rapport contient chacune d'elles, prête à rejouer.
Rattacher chaque requête à l'entreprise du compte connecté, côté serveur, et filtrer toutes les lectures par elle.
PrioritéImmédiate, retest inclus
Une route d'administration appelable par un compte standard : le contrôle n'existait que dans l'interface, qui masquait le bouton.
GravitéCritique, depuis un compte standard
Requêtes, captures et étapes de reproduction : caviardées dans cet exemple. Votre rapport contient chacune d'elles, prête à rejouer.
Vérifier le rôle côté serveur dans chaque fonction d'administration, quel que soit l'écran qui l'appelle.
PrioritéImmédiate, retest inclus
Matrice de droits testée
Ce que chaque rôle doit pouvoir faire, ce qu'il peut vraiment faire, et chaque écart prouvé.
Requêtes rejouables
Chaque franchissement avec sa requête et sa preuve, que vos développeurs rejouent avec deux comptes de test.
Impact métier
Quelles données, quels comptes, quelles entreprises clientes sont exposés, dit en clair pour votre direction.
La vérification qui manque
Pour chaque faille, le contrôle à ajouter côté serveur et l'endroit où l'ajouter.
Retest inclus
Après vos corrections, nous rejouons l'ensemble des cas concernés, pas seulement la faille d'origine.
Restitution & échange
Un échange avec vos développeurs pour parcourir la matrice et prioriser les corrections.
Combien ça coûte.
Sur devis, et voici pourquoi : le travail dépend de la taille de votre matrice de droits, qui ne se mesure qu'au cadrage. Pour vous situer, voici nos tarifs selon le type de mission.
À partir de7 500 € TTC
Application métier ou SaaS
Dix à quinze jours ou plus. Plusieurs rôles, plusieurs entreprises clientes : la matrice de droits complète.
À partir de3 200 € TTC
API ciblée
Quatre à huit jours. Les contrôles d'accès d'une API, vérifiés pour chaque rôle.
À partir de2 700 € TTC
Site vitrine ou boutique
Quatre à six jours. L'espace client d'un site ou d'une boutique, avec un ou deux rôles : accès entre comptes, sessions et reprise de compte.
Ce qui fait varier le prix
Le nombre de rôles, d'abord : chaque rôle ajouté croise tous les autres, et le nombre de cas à rejouer grandit vite.
Ensuite le nombre d'entreprises clientes qui partagent la plateforme, et la présence d'une application mobile qui refait ses propres contrôles : chacune ajoute une frontière à tester.
Un premier échange, sans engagement, suffit à mesurer votre matrice. Si elle est plus petite que prévu, nous vous le dirons.
25vérifications de droits
Doit être accordéDoit être refusé
Chaque case est une vérification. Ce rôle a-t-il le droit de faire cette action, et le serveur le vérifie-t-il vraiment ? Ajoutez un rôle, et c'est une colonne entière à franchir.
Vos droits d'accès, prouvés.
Les référentiels de sécurité demandent tous de restreindre les accès, puis de vérifier que la restriction tient. Notre rapport en est la preuve : matrice testée, méthode, franchissements et corrections vérifiées.
ISO/IEC 27001
Annexe A, mesures 5.15, 8.3 et 8.29
Contrôle d'accès, restriction d'accès à l'information, tests de sécurité : le rapport montre la matrice testée et ce qui a cédé.
PCI DSS
Exigences 7, 8 et 11.4
Restreindre l'accès aux données de carte au strict besoin, identifier chaque utilisateur, puis le tester.
SOC 2
Critère CC6.1
Les accès logiques sont au cœur des critères CC6 : un test indépendant de vos contrôles d'accès en est la preuve.
RGPD
Article 32
Un client qui lit les données d'un autre, c'est une violation de données. Le rapport trace les tests et les corrections.
NIS 2
Article 21
Des politiques de contrôle d'accès, et l'évaluation de leur efficacité : la matrice testée en fait la démonstration.
DORA
Articles 9 et 24
Pour les entités financières, des accès limités au strict nécessaire, et des tests qui le vérifient.
Nous ne délivrons pas de certification : nous fournissons la preuve technique que vos auditeurs demandent. Le contrôle d'accès défaillant est la première catégorie du Top 10 de l'Fondation à but non lucratif qui publie les référentiels de sécurité les plus utilisés, dont le Top 10 des risques des applications web.. Notre méthode suit la structure du Penetration Testing Execution Standard : la trame d'une mission de test d'intrusion, du cadrage au rapport., détaillée ici.
En quoi est-ce différent d'un test d'intrusion classique ?
Un test d'intrusion couvre large : injections, configuration, exposition, permissions. Cette mission ne traite qu'un seul axe, mais en profondeur. Là où un test généraliste vérifie quelques accès emblématiques, ici nous construisons la matrice complète et nous en vérifions chaque case. C'est le bon choix quand votre application a beaucoup de rôles ou plusieurs entreprises clientes.
Combien de comptes de test faut-il prévoir ?
Au minimum deux comptes de même niveau, sans quoi l'accès horizontal est intestable : il faut pouvoir tenter d'atteindre les données de l'un depuis l'autre. Ensuite un compte par niveau de privilège, et si votre plateforme accueille plusieurs entreprises clientes, deux entreprises distinctes avec leurs propres données.
Vous testez sur la production ou sur un environnement dédié ?
Un environnement de préproduction proche de la production est idéal, parce qu'il autorise des manipulations qu'on s'interdit ailleurs. Sur la production, nous travaillons uniquement avec des comptes et des données créés pour l'audit, et nous ne faisons rien de destructif. Les deux fonctionnent, l'essentiel est de le décider avant.
Pourquoi les scanners passent-ils à côté de ces failles ?
Parce qu'un outil ne connaît pas votre modèle de droits. Quand il envoie une requête et reçoit un code 200 avec des données, il conclut que tout va bien : rien dans la réponse ne lui dit que ce compte n'aurait pas dû les voir. Cette information n'existe que dans votre tête et dans vos spécifications.
On a du SSO et du MFA, est-ce que ça ne règle pas la question ?
Cela règle l'authentification, c'est-à-dire la preuve que vous êtes bien vous. Cela ne dit rien de l'autorisation, c'est-à-dire ce que vous avez le droit de faire une fois entré. La majorité des failles que nous trouvons ici touchent des utilisateurs parfaitement authentifiés, souvent avec un second facteur.
Les autres prestations.
Les permissions ne sont qu'un axe ? Une autre mission peut couvrir le reste.
Test d'intrusion web
Si vous voulez une couverture large plutôt qu'un axe unique, le test d'intrusion web inclut les permissions parmi d'autres familles de failles.
Voir la prestationAudit de sécurité d'API
Quand l'application expose une API, les mêmes frontières doivent être vérifiées côté routes, où l'interface ne masque plus rien.
Voir la prestationAudit de sécurité de site web
Pour un site vitrine, une boutique ou un CMS : l'exposition, l'hébergement et les formulaires.
Voir la prestationAudit de sécurité WordPress
Si votre espace membres tourne sous WordPress, ses rôles et ses extensions demandent une approche propre.
Voir la prestationFaites auditer vos contrôles d'accès.
Votre espace client est une cible.
Dites-nous combien de rôles distincts existent dans votre application, si plusieurs entreprises clientes cohabitent, et si une API mobile refait ses propres contrôles. Nous vous répondons avec un cadrage et un devis. Premier échange sans engagement.