Les utilisateurs peuvent remplacer `?account_id=123` par `124` et voir les données d'autres utilisateurs. De quelle catégorie s'agit-il, et comment corriger ?

Lorsque remplacer account_id=123 par 124 renvoie les données de quelqu'un d'autre, l'application identifie l'objet mais ne demande jamais si cet utilisateur a le droit de le voir. C'est une référence directe à un objet non sécurisée (IDOR), une forme de contrôle d'accès défaillant — la catégorie de risque numéro un de l'OWASP.

La bonne correction : autorisation au niveau objet côté serveur

À chaque requête touchant un objet précis, le serveur doit vérifier que le principal authentifié est autorisé pour cet objet exact — par exemple que le compte appartient à l'utilisateur courant (ou est partagé avec lui) — et refuser sinon. Cette vérification doit résider côté serveur et s'exécuter sur tous les chemins d'accès, pas seulement l'interface qui « normalement » affiche le bon compte. La référence elle-même peut rester un simple entier ; ce qui compte, c'est la décision d'autorisation derrière elle.

Pourquoi les distracteurs sont faux

• Nettoyer le nombre valide le format, pas la propriété. 124 est un entier parfaitement valide qui appartient pourtant à quelqu'un d'autre.
• Chiffrer ou masquer l'account_id relève de la sécurité par l'obscurité. Les ID chiffrés ou aléatoires fuient dans les URL, les journaux, les en-têtes Referer et l'historique du navigateur, et peuvent être rejoués ; passer aux UUID relève le seuil de devinette mais renvoie toujours les données à quiconque obtient une référence valide. Le vrai défaut est l'absence de vérification d'autorisation.
• Passer de GET à POST change le verbe HTTP et l'emplacement du paramètre, pas le fait que le serveur autorise la requête. L'attaquant envoie simplement un POST.

Ce que l'examinateur cherche à évaluer

Il veut que vous nommiez correctement la classe de vulnérabilité (contrôle d'accès défaillant / IDOR), que vous résistiez aux corrections tentantes mais superficielles, et que vous placiez le contrôle au bon endroit : une décision d'autorisation par objet, côté serveur, appliquée uniformément. Les bons candidats ajoutent que cela s'applique idéalement de façon centralisée — via une couche d'autorisation partagée ou un middleware — pour qu'aucun point de terminaison n'oublie la vérification, et que l'obscurcissement n'est au mieux qu'une défense en profondeur, jamais le correctif.