3 min read Page Views

Absence de contrôle d’accès sur les endpoints API

(Broken Authentication / Broken Object Level Authorization)

Contexte

Dans le cadre d’un pentest whitebox réalisé sur l’API REST FastAPI de HealthNorth, en complément de l’analyse de risques menée en amont, l’objectif était de vérifier si les risques identifiés de façon théorique étaient réellement exploitables en conditions pratiques.

Méthodologie

Dans le cadre d’un test en whitebox, j’ai eu accès à l’intégralité du code source et de l’architecture de l’application, celle-ci ayant été développée par mes soins dans le cadre du projet E6 de mon BTS. Cette connaissance permet d’orienter directement l’analyse vers les zones à risque, plutôt que de passer par une phase de reconnaissance en boîte noire qui serait nécessaire sur une cible inconnue.

L’examen du code des routes a permis d’identifier que les endpoints exposant des données patients ne déclarent aucune dépendance de vérification d’authentification (Depends(get_current_user) ou équivalent), alors que celle-ci serait attendue pour des données de santé catégorie de données sensibles au sens de l’article 9 du RGPD.

Cette observation a été formulée comme hypothèse, puis validée empiriquement avant d’être consignée comme finding.

Endpoints concernés

Méthode Route Description
GET /patients/{id_patient} Récupération du dossier d’un patient
GET /patient/{id_user} Récupération des ordonnances d’un patient
GET /rdv/patient/{id_user} Récupération des rendez-vous d’un patient

Validation

Test réalisé depuis l’interface Swagger UI (/docs) générée automatiquement par FastAPI, sans authentification préalable ni token transmis dans les en-têtes.

Requête :

GET /patients/1 HTTP/1.1
Host: 127.0.0.1:8000

Réponse obtenue : 200 OK accompagné du contenu intégral du dossier patient (identité, données médicales associées), alors qu’aucune session, cookie ou token Bearer n’a été fourni.

Le test a été répété sur plusieurs identifiants consécutifs (/patients/1, /patients/2, /patients/3), confirmant que l’absence de contrôle s’applique à l’ensemble des ressources et non à un cas isolé.

Mon image

Analyse d’impact

Rattachement à la grille DICP établie lors de l’analyse de risques :

  • Confidentialité — impact maximal : accès en lecture à l’intégralité des dossiers médicaux sans authentification
  • Disponibilité — non impactée directement sur ce endpoint (lecture seule)
  • Intégrité — toutes les routes PUT/DELETE souffrent du même défaut, l’intégrité des données est également compromise
  • Preuve — aucune traçabilité possible : l’absence d’authentification empêche tout audit log fiable de qui a consulté quelle donnée, et quand

Sur le plan réglementaire, ce constat constitue une violation potentielle de l’article 32 du RGPD (sécurité du traitement) appliqué à des données de santé, catégorie qualifiée de “sensible” par l’article 9.

Sévérité

Critique

Justification : exploitation triviale ne nécessitant aucune compétence technique particulière, aucune authentification requise, impact direct et massif sur la confidentialité de données de santé.

  • CWE associée : CWE-306 – Missing Authentication for Critical Function
  • OWASP API Security Top 10 : API2:2023 – Broken Authentication

Remédiation

Ajout d’une dépendance d’authentification et d’une vérification de propriété sur chaque route exposant des données sensibles :

# Avant
@router.get("/patients/{id_patient}")
def get_patient(id_patient: int, db: Session = Depends(get_db)):
    ...

# Après
@router.get("/patients/{id_patient}")
def get_patient(
    id_patient: int,
    db: Session = Depends(get_db),
    current_user: User = Depends(get_current_user)
):
    if current_user.id != id_patient and current_user.role != "medecin":
        raise HTTPException(status_code=403, detail="Accès non autorisé")
    ...

Au-delà du correctif ponctuel route par route, il est recommandé d’introduire un middleware global ou une dépendance appliquée par défaut sur l’ensemble des routes sensibles, afin d’éviter tout oubli lors de l’ajout de futurs endpoints.

Conclusion

Ce finding confirme, en conditions pratiques, un risque qui avait été identifié de façon théorique lors de l’analyse de risques EBIOS RM réalisée en amont du projet. Il illustre l’intérêt de valider par des tests d’intrusion les hypothèses posées lors d’une analyse purement documentaire la théorie identifiait le risque, le pentest en a confirmé l’exploitabilité réelle.