Connexion générée par IA : cacher un bouton ne protège pas une API
Un laboratoire local vérifie l’accès d’un propriétaire, d’un autre compte et d’un utilisateur anonyme avant et après contrôle serveur.
Le contrôle doit exister sur la route
L’écran peut masquer un bouton pour un utilisateur et laisser la route correspondante accessible. Le laboratoire construit volontairement ce défaut avec un document fictif appartenant à Alice. Bob ne devrait pas le lire. Dans l’état initial, la requête directe de Bob reçoit pourtant une réponse 200.
Le scénario n’est pas le résultat d’un audit de générateur d’applications. Il explique une frontière de sécurité à vérifier, quelle que soit l’origine du code. Les requêtes ont été exécutées uniquement contre le serveur local créé pour l’article.
Séparer l’identité et le droit sur l’objet
L’authentification établit une identité selon le mécanisme choisi. L’autorisation décide si cette identité peut accomplir cette action sur cette ressource. Dans cet exemple, la connexion d’un compte ne lui donne pas accès au document d’un autre propriétaire.
Le support remplace l’authentification par un en-tête x-demo-user afin d’isoler la décision d’autorisation. Cet en-tête est falsifiable et ne doit pas être repris comme mécanisme de connexion. Une application réelle doit obtenir l’identité depuis une session ou un jeton vérifié côté serveur.
Une matrice minimale exécutée
Ressource : doc-a, propriétaire : alice
Avant contrôle : bob -> 200, défaut volontaire
Après contrôle :
anonyme -> 401
bob, autre propriétaire -> 403
alice, propriétaire -> 200const status = !user ? 401
: user !== document.owner ? 403
: 200;Le script vérifie ces statuts avec des assertions et ferme le serveur après l’essai. Il n’inclut aucun secret réel. Dans certains contrats d’API, une réponse 404 pour une ressource inaccessible peut éviter d’en révéler l’existence ; définir ce choix et le vérifier de manière cohérente.
Étendre selon les actions réellement offertes
- Vérifier lecture, modification et suppression, pas seulement l’écran principal.
- Contrôler les identifiants de ressource fournis par le client et les droits à chaque requête.
- Prévoir les rôles d’administration avec un périmètre explicite.
- Tester l’absence d’identité et le compte d’un autre propriétaire avec des données fictives.
L’ASVS d’OWASP fournit un cadre d’exigences de sécurité. Ce laboratoire n’en couvre qu’une décision simplifiée et ne constitue pas une revue complète. Il ne teste ni création de session, ni renouvellement, ni révocation des droits, ni isolation au niveau de la base.
Lors d’une demande à un agent, joindre la matrice des autorisations et les tests de refus attendus. La présence d’un écran de connexion convaincant ne dispense jamais de rejouer ces requêtes dans l’environnement autorisé.
