Autorisation et contrôle d'accès

L'authentification est un problème résolu : il existe une bonne réponse, et Spring Security la fournit. L'autorisation, elle, est un problème de conception, et c'est là que se logent les failles intéressantes. Un attaquant n'a pas besoin de casser votre hachage BCrypt s'il peut consulter la facture d'un autre client en changeant un identifiant dans l'URL. L'OWASP place ce type de défaut — le contrôle d'accès défaillant — en tête de son classement des risques.

Ces défauts partagent une caractéristique : ils ne provoquent aucune erreur. Une règle d'autorisation trop large ne plante pas ; elle autorise. Une règle placée derrière une autre qui l'absorbe ne signale rien ; elle est simplement ignorée. Une annotation @PreAuthorize sur une méthode appelée depuis la même classe ne s'applique pas ; l'appel réussit. Dans les trois cas, les tests fonctionnels passent, la démonstration se déroule bien, et l'accès est ouvert.

Cette leçon traite l'autorisation à deux niveaux. Au niveau des URL, avec authorizeHttpRequests, qui protège l'entrée du bâtiment. Au niveau des méthodes, avec @PreAuthorize, qui protège chaque pièce — et qui seule permet de répondre à la question « cette facture appartient-elle bien à l'appelant ? », question qu'une règle d'URL est structurellement incapable de trancher.