Une application de prise de notes permet à Alice d’enregistrer un « Projet de budget trimestriel » sous la note n° 1. Bob se connecte à son propre compte, effectue une requête GET /notes/1 et reçoit la note d’Alice, car le serveur vérifie bien que Bob est connecté mais ne vérifie jamais si Bob est le propriétaire de la note n° 1. Bob n’a eu besoin ni du mot de passe d’Alice ni d’un accès particulier ; un simple identifiant prévisible a suffi. Si Bob demande la note n° 1, l’API devrait-elle renvoyer le contenu d’Alice ? Le petit exemple local ci-dessous illustre la requête et la réponse non sécurisées :
Ce code renvoie l’enregistrement JSON d’Alice tout en identifiant Bob comme l’utilisateur à l’origine de l’action. La défaillance observée est un contrôle d’accès défaillant (broken access control), situation dans laquelle le serveur autorise une personne authentifiée à effectuer une action dépassant ses droits. La mesure préventive immédiate consiste à vérifier la propriété côté serveur avant de lire la note ; l’indicateur de détection est une entrée de journal consignant Bob, la note n° 1 et un refus d’autorisation. Nous continuerons à corriger cette application de notes, afin que chaque règle de sécurité reste associée à une requête, à un segment de code et à une méthode de vérification de la correction.
L’absence de vérification de la propriété est critique car le navigateur se trouve en dehors de la limite de confiance du serveur API. Une limite de confiance (trust boundary) désigne le point où l’application reçoit des données ou une instruction pouvant être influencées par une tierce partie ; le serveur doit donc les valider et appliquer ses propres règles. Le cookie de Bob et l’identifiant de la note demandée transitent d’un client non fiable vers le serveur ; l’API n’envoie ensuite une requête à la base de données qu’après avoir pris la décision d’autorisation.
Cette même application comporte plusieurs points d’entrée. Un internaute non authentifié peut soumettre des identifiants de connexion ou créer une note. Un utilisateur disposant de privilèges restreints, comme Bob, peut fournir des identifiants et du contenu de notes après s’être connecté. Une dépendance compromise peut s’introduire lors de la phase de construction (build), lorsque le registre de paquets fournit du code que le serveur exécutera ultérieurement. Les actifs à protéger sont les sessions actives, les notes d’Alice, les secrets du serveur et les journaux indiquant quelles requêtes ont été effectuées. Le diagramme suit chaque donnée d’entrée jusqu’au composant chargé de décider s’il convient de lui faire confiance :