Partie 5 — Autorisation & contrôle d’accès

⏱️ TL;DR — Une fois qu’on sait qui est l’utilisateur (authentification, Partie 4), il faut décider ce qu’il a le droit de faire : c’est l’autorisation. Et c’est, statistiquement, le risque n°1 des applis web — le Broken Access Control trône en tête du Top 10 OWASP. Sa forme la plus courante est l’IDOR (Insecure Direct Object Reference, ou BOLA côté API) : accéder à la ressource d’un autre en changeant un identifiant (/facture/123 → /facture/124). Cette partie distingue authn et authz, présente les modèles (RBAC, ABAC), dissèque l’IDOR et le broken access control, et martèle la règle qui les ferme : vérifier l’autorisation côté serveur, sur chaque requête, pour chaque objet — jamais se fier au client ni à l’obscurité d’un id.

Le problème qu’on résout

Authentifier ne suffit pas. Une fois connecté, un utilisateur ne doit accéder qu’à ce qui le concerne et n’effectuer que les actions permises par son rôle. Le drame, c’est que le contrôle d’accès est facile à oublier : la fonctionnalité « marche » (l’utilisateur voit sa facture), les tests passent (on teste toujours avec le bon utilisateur), et personne ne remarque qu’en changeant un id dans l’URL, on voit la facture de quelqu’un d’autre. Aucune erreur, aucun crash — juste une fuite massive qui attend d’être trouvée.

C’est précisément pour ça que le Broken Access Control est si répandu : il ne se manifeste que si on pense à l’attaquer. Cette partie t’apprend à y penser systématiquement et à écrire le contrôle qui le ferme.

Ce que tu sauras faire à la fin de cette partie

• Distinguer clairement authentification (qui es-tu) et autorisation (qu’as-tu le droit de faire).
• Choisir un modèle de droits : RBAC (par rôles), ABAC (par attributs), et leurs combinaisons.
• Reconnaître et exploiter mentalement un IDOR/BOLA pour mieux le fermer.
• Appliquer la règle d’or : vérifier l’appartenance et les droits côté serveur, à chaque requête, par objet.
• Sécuriser un contexte multi-tenant (isolation stricte entre organisations/clients).

Les chapitres

Une fois l’accès verrouillé, on descend d’un cran vers les attaques qui manipulent les données elles-mêmes : la Partie 6 — Injections, où une entrée non fiable se fait passer pour du code.

On commence par la distinction qui structure tout : Authn ≠ Authz & modèles.