Tests
Prouver que l'accès est refusé, pas seulement qu'il est accordé.
Tests de sécurité
Une configuration de sécurité a une propriété désagréable : elle échoue silencieusement dans le sens qui compte. Si une règle est trop stricte, vous l'apprenez en trente secondes — quelqu'un se plaint de ne pas pouvoir accéder à une page. Si elle est trop permissive, personne ne se plaint. Jamais. L'application fonctionne, tout le monde accède à ce qu'il veut, et le défaut est découvert par un audit, ou par quelqu'un de moins bien intentionné.
Les tests de sécurité corrigent cette asymétrie, et ils ont une particularité : les cas intéressants sont les cas négatifs. Un test qui vérifie qu'un administrateur atteint la console d'administration a peu de valeur ; ce chemin est parcouru en permanence. Le test qui compte est celui qui vérifie qu'un utilisateur ordinaire reçoit un 403, qu'un anonyme reçoit un 401, et qu'un client ne peut pas lire la facture d'un autre client.
Ces tests ont une seconde vertu : ils documentent votre modèle de droits sous une forme exécutable. Quand quelqu'un ajoutera une règle dans six mois et absorbera par accident une règle plus spécifique, c'est le test négatif qui l'arrêtera — pas la relecture.
Commentaires
Les commentaires sont alimentés par GitHub Discussions
Connectez-vous avec GitHub pour participer à la discussion