API REST à l'examen : E6 et E7 SLAM, cas corrigé

Réponse modèle. Non. Le code 403 Forbidden signifie que l'utilisateur est authentifié mais n'a pas le droit d'accéder à la ressource. Ici, l'API ne sait pas qui appelle : le jeton est absent, invalide ou expiré. Le code adapté est 401 Unauthorized, accompagné de l'en-tête WWW-Authenticate: Bearer. En recevant 401, l'application mobile tente d'obtenir un nouveau jeton d'accès avec son jeton de rafraîchissement, et à défaut redemande à l'abonné de se connecter. Avec 403, elle croirait à un refus définitif et afficherait un message trompeur.

Réponse modèle. Le client 198.51.100.23 envoie en une seconde cinq requêtes sur des identifiants d'abonnés consécutifs (20417 à 20421) et obtient chaque fois 200 avec des réponses de tailles différentes, donc de vraies données : il énumère les abonnés et récupère leurs trajets. Un abonné connecté ne peut être qu'un seul de ces abonnés : l'API renvoie donc les trajets d'autres abonnés.

La faille est un contrôle d'accès à l'objet défaillant (Broken Object Level Authorization, BOLA, risque API1:2023 de l'OWASP API Security Top 10). Le document 2 vérifie l'authentification (lignes 4 à 8 : un jeton valide est exigé) mais jamais l'autorisation : aucune ligne ne compare $idAbonne à l'identifiant de l'utilisateur connecté ($utilisateur['id']). Tout abonné authentifié lit les trajets de tous les autres.

La dernière ligne du journal montre un appel sans jeton valide, refusé : l'authentification fonctionne, ce qui confirme que c'est bien l'autorisation qui manque.

Réponse modèle. Le critère atteint est la confidentialité. Les données exposées sont des données personnelles au sens du RGPD : nom, prénom, téléphone, adresse, et surtout l'historique des déplacements (stations, dates, heures), qui révèle les habitudes de vie, le domicile et le lieu de travail des abonnés. Pour Vélivert, c'est une violation de données personnelles : elle doit être documentée dans le registre des violations et notifiée à la CNIL dans les 72 heures, puisqu'elle est susceptible d'engendrer un risque pour les personnes ; et comme ce risque est élevé (localisation, coordonnées), les abonnés concernés doivent aussi être informés. S'y ajoutent l'atteinte à l'image du service et un risque de sanction. Les obligations en cas de violation sont détaillées dans le cours Droit du numérique et RGPD.

 4      $utilisateur = $this->verifierJeton($this->lireJetonBearer());
 5      if ($utilisateur === null) {
 6          header('WWW-Authenticate: Bearer realm="api"');
 7          $this->repondre(401, ['erreur' => 'Authentification requise']);
 8          return;
 9      }
10      $estSupport = $utilisateur['role'] === 'support';
11      if (!$estSupport && $utilisateur['id'] !== $idAbonne) {
12          $this->repondre(404, ['erreur' => 'Abonné introuvable']);
13          return;
14      }
15      $sql = "SELECT id, date_depart, station_depart, station_arrivee, duree_min
16              FROM trajet WHERE id_abonne = :id
17              ORDER BY date_depart DESC LIMIT 50";
18      $requete = $this->pdo->prepare($sql);
19      $requete->execute(['id' => $idAbonne]);
20      $this->repondre(200, $requete->fetchAll(PDO::FETCH_ASSOC));

Les corrections, et pourquoi :

• 401 au lieu de 403 quand il n'y a pas de jeton valide, avec WWW-Authenticate (question 1) ;
• le contrôle d'autorisation (lignes 10 à 14) : un abonné ne passe que si l'identifiant demandé est le sien ; le rôle support passe toujours. Le code 404 évite de confirmer l'existence de l'abonné demandé ; 403 serait aussi accepté. La comparaison !== suppose que verifierJeton renvoie un id de type entier, comme $idAbonne ;
• la minimisation des données : la jointure avec abonne et les colonnes nom, prenom, telephone, adresse disparaissent. L'application n'en a pas besoin, et les renvoyer était une exposition excessive de propriétés (BOPLA, API3:2023) contraire au principe de minimisation du RGPD ;
• la requête préparée : le paramètre typé int rendait l'injection impossible ici, mais la concaténation reste une mauvaise pratique qui deviendrait une faille au premier changement de type. La requête préparée est la norme (injection SQL) ;
• une limite (LIMIT 50) : un abonné ancien peut avoir des milliers de trajets ; sans limite, la réponse grossit sans fin (API4:2023). Une vraie pagination (?page=, ou un curseur sur date_depart) compléterait la correction.

Réponse modèle. Deux mesures parmi :

• une limitation de débit par jeton et par adresse IP (par exemple 60 requêtes par minute sur cette route), avec une réponse 429 Too Many Requests : l'énumération aurait été fortement ralentie ;
• des identifiants non prévisibles (UUID) dans les URI à la place des entiers consécutifs : on ne devine plus l'identifiant suivant. C'est une défense complémentaire, qui ne remplace pas le contrôle d'autorisation ;
• une alerte sur le journal : un même jeton qui accède à des ressources de plusieurs abonnés différents en quelques secondes déclenche une alerte, voire le blocage automatique de l'adresse IP (un outil comme fail2ban, ou un pare-feu applicatif) ;
• des tests d'autorisation automatisés : pour chaque route qui prend un identifiant, un test vérifie qu'un abonné A n'accède pas aux données de l'abonné B.

Réponse modèle. La proposition est à rejeter. Un jeton d'abonné donne accès aux routes de l'API des abonnés (profil, trajets, paiement) alors que l'office n'a besoin que de la disponibilité des stations : c'est contraire au moindre privilège. Le jeton, utilisé par le site de l'office, risque aussi d'être exposé dans son code, et il expire : il faudrait une connexion automatisée avec un mot de passe stocké chez l'office.

La disponibilité des stations n'est pas une donnée personnelle et n'a rien de confidentiel. Il vaut mieux créer une route publique en lecture seule, séparée de l'API des abonnés, par exemple GET /api/v1/stations, qui renvoie pour chaque station son identifiant, son nom, sa position et le nombre de vélos et de places disponibles. Elle n'a aucune route de modification. On la protège par une limitation de débit, et par une mise en cache d'une minute (Cache-Control: public, max-age=60) qui correspond au besoin et allège le serveur. Si Vélivert veut suivre l'usage par partenaire, elle peut attribuer à l'office une clé d'API limitée à cette route, utilisée depuis le serveur de l'office et jamais dans le code de ses pages.

Réponse modèle. HTTPS chiffre les échanges entre l'application et l'API : il garantit la confidentialité et l'intégrité des données pendant le transport et authentifie le serveur, ce qui empêche le vol du jeton sur le réseau. Mais il ne contrôle pas ce que l'API accepte de faire : l'attaque du document 1 a eu lieu en HTTPS, avec un jeton valide. La sécurité d'une API repose aussi sur l'authentification de chaque requête, le contrôle d'autorisation sur chaque objet, la minimisation des données renvoyées, la validation des entrées et la limitation de débit. HTTPS est nécessaire, pas suffisant.