Qui fait la demande ?
Configurer deux identités de test. Savoir qui émet une requête est le point de départ, pas la preuve d’un droit d’accès à chaque objet.
TEST_USER_ID_SELF / TEST_USER_ID_OTHERCyberScope
La confiance se vérifie.
Transformer les questions en API security en contrôles automatisés et réutilisables.
À la loupe / API authorization
Une requête.Trois questions.
Scénario de test illustratif · aucun résultat d’exécution
À quoi peut-on accéder ?
Demander la ressource d’une autre identité avec le compte configuré. L’endpoint et les données de test doivent permettre ce scénario.
BOLA / Broken Object Level AuthorizationQue prouve la réponse ?
Examiner la réponse au regard de la politique d’accès attendue. Les rapports HTML et JSON rendent le contrôle vérifiable ; un succès HTTP seul ne prouve pas des droits d’accès corrects.
Rapports HTML / JSON · Jenkins- Politique attendue
- Droits d’accès configurés
- Réponse observée
- Comparer à la politique
- Rapport produit
- Preuves HTML + JSON
Même endpoint. Autre identité.
Scénario illustratif fondé sur la configuration BOLA documentée. Aucun résultat d’exécution n’est présenté.
Deux identités de test
TEST_USER_ID_SELF et TEST_USER_ID_OTHER définissent l’ownership boundary.
Franchir cette frontière
Demander la ressource d’un autre utilisateur avec l’identité configurée. L’endpoint doit permettre ce scénario.
Analyser la réponse
Examiner l’authorization dans le rapport généré. Un succès HTTP ne prouve pas que les droits d’accès sont corrects.
La question utile : cette identité doit-elle avoir accès à cette ressource ?
Lire la source ↗01 / La question
Une API peut répondre correctement tout en exposant la mauvaise ressource. Comment intégrer des tests reproductibles d’authentication, d’authorization et d’input validation au travail d’ingénierie ?
02 / Contribution au projet
Un framework réutilisable de tests en API security : suites Robot Framework, fonctions Python et intégration Jenkins. Une API de démonstration FastAPI offre un environnement contrôlé pour développer les vérifications.
03 / Dans l’implémentation01 02 03
Configurer la cible
Définir l’URL, la stratégie d’authentication et les identités de test. La découverte fondée sur OpenAPI aide à adapter la suite.
Vérifier les frontières
Les contrôles documentés couvrent authentication, BOLA, malformed inputs, information disclosure et rate limiting. Les tests avancés dépendent de la configuration.
Examiner les preuves
L’orchestration Jenkins et les rapports HTML / JSON relient l’exécution aux résultats examinables.
04 / Périmètre & enseignements
Un outil de test ne garantit pas la sécurité d’une API. BOLA nécessite des identités et des endpoints adaptés ; certains contrôles optionnels peuvent être ignorés. Les affirmations de couverture et de performance du dépôt n’ont pas été validées indépendamment.