Fournit des méthodes de test, des preuves, une surveillance, des alertes, des mesures correctives et des étapes de réponse aux incidents pour le CSRF. Cette référence fixe la limite d’adoption, le comportement en cas d’échec et les preuves observables tout en laissant les limites spécifiques à l’environnement configurables.
Statut du package : contexte de référence prêt pour revue humaine. Le contrat et les scénarios de test sont complets, mais aucune affirmation n’est faite quant à la réussite de leur passage par une implémentation adoptante.
Décision
Pour le CSRF, adopter un modèle de menace et un contrôle appliqué par le serveur à la frontière protégée. Traiter le bloc comme un contrat de publication et de régression construit à partir de cas positifs représentatifs, de cas limites, de refus, d’échecs et de récupération. Ce package est un contrat de référence : l’équipe adoptante doit choisir les limites numériques, les fournisseurs, les juridictions et les responsables opérationnels à partir des preuves dans son propre environnement.
Portée
- Les acteurs CSRF, entrées, sorties, états, versions de politique ou de schéma, et résultats visibles de l’extérieur décrits par ce bloc de test.
- Interfaces principales et alternatives, travaux en arrière-plan, caches, intégrations, chemins de support et preuves pouvant exercer la même frontière.
- Configuration spécifique à l’adoption, déploiement, récupération et responsabilités de vérification nécessaires pour appliquer la référence en toute sécurité.
Hors de ce bloc
- Choisir un fournisseur universel, un framework, une juridiction, un seuil numérique, une période de rétention ou un objectif de niveau de service pour chaque adoptant.
- Affirmer que les scénarios packagés ont été exécutés contre une implémentation en aval ou que cette référence accorde une certification légale, de sécurité ou d’accessibilité.
Contrat
- Nommer les actifs, acteurs, frontières de confiance, capacités de l’attaquant, cas d’abus, hypothèses et risques résiduels avant de sélectionner les contrôles.
- Échouer en mode fermé pour les opérations protégées lorsque l’identité, la politique, l’intégrité, la fraîcheur ou la portée des ressources ne peuvent être établies.
- Limiter le travail et les tentatives par acteur, identifiant, locataire, ressource et capacité d’infrastructure sans se fier uniquement à l’identité fournie par le client.
- Garder secrets et charges utiles sensibles hors des journaux tout en conservant la version du contrôle, la corrélation, la décision et la raison sûre comme preuves.
- Enregistrer la version du fixture, l’environnement, la configuration, le résultat observé et l’emplacement des preuves pour chaque exécution portant une décision.
- Séparer les échecs produit, échecs de dépendance, échecs d’infrastructure de test et preuves non concluantes dans les rapports.
- Protéger chaque requête navigateur modifiant l’état avec un design anti-forgery conscient de l’origine tel qu’un jeton imprévisible lié à la session et des cookies SameSite à portée appropriée.
- Rejeter les méthodes non sûres sans preuve valide avant effets secondaires, éviter les changements d’état via GET, revalider les redirections et types de contenu alternatifs, et tester les flux de connexion, déconnexion, upload, API et intégrés.
Conseils d’implémentation
- Construire l’ensemble de fixtures déterministes le plus petit couvrant les classes de risque, puis ajouter des cas dérivés de la production uniquement après revue respectueuse de la vie privée.
- Modéliser les entrées, sorties, acteurs, états, invariants, effets secondaires et preuves du CSRF avant de sélectionner les détails du framework ou du fournisseur.
- Stocker la version applicable du contrat ou de la politique CSRF avec l’état matériel afin que les migrations, rejouages et décisions de support restent attribuables.
- Introduire le chemin derrière un déploiement contrôlé, comparer les résultats attendus et observés, et conserver une route de récupération testée jusqu’à ce que les preuves d’adoption soient complètes.
Gestion des échecs et protections
- La dégradation du contrôle préserve la frontière protégée, déclenche un signal d’incident possédé, et ne donne jamais accès uniquement pour maintenir la disponibilité.
- L’état CSRF invalide ou contradictoire est rejeté ou mis en quarantaine ; l’implémentation ne devine jamais une valeur qui élargit l’autorité ou duplique un effet.
- Les tentatives sont limitées et utilisent une identité durable ; après épuisement, le travail atteint un état terminal inspectable avec un propriétaire responsable.
Vérification et opérations
- Exécuter la suite deux fois à partir d’un état propre et confirmer que l’ordre, les tentatives et l’exécution parallèle ne changent pas le verdict.
- Surveiller le succès CSRF, refus, échec de validation, échec de dépendance, épuisement des tentatives et récupération par version de contrat sans dimensions de charge utile sensibles.
- Réexécuter les fixtures positives et négatives appariées après changements de politique, schéma, dépendance, migration ou frontière et conserver les preuves résultantes.
Hypothèses d’adoption
- Les noms et valeurs dans l’exemple sont un fixture concret, pas des valeurs par défaut universelles ; les adoptants les remplacent par des preuves documentées et une propriété.
- Le système adoptant peut fournir une identité authentifiée, des versions durables d’opérations ou d’enregistrements, une télémétrie limitée et un chemin contrôlé pour les changements.
Les exemples à l’apparence exécutable dans ce package sont des fixtures et des contrats d’acceptation. Exécutez le validateur de collection pour vérifier la structure et les métadonnées, puis traduisez et exécutez les scénarios dans le dépôt cible avant d’enregistrer les preuves d’implémentation.