XSS : Spécification de contrôle
Définit les actifs, les menaces, les frontières de confiance, les contrôles requis, les valeurs par défaut sécurisées et les directives de mise en œuvre pour le XSS. 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 ces tests par une implémentation adoptante.
Décision
Pour le XSS, adopter un modèle de menace et un contrôle appliqué côté serveur à la frontière protégée. Faire respecter le contrôle côté serveur de confiance, refuser par défaut, et définir les hypothèses de menace, les limites d’abus, les preuves et la 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 XSS, 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 sécurité.
- 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 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 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.
- Traiter tous les champs client, callback, fichier, modèle et télémétrie comme non fiables jusqu’à authentification et validation pour l’action prévue.
- Exiger une seconde sauvegarde indépendante pour les chemins à fort impact où la compromission d’un parseur, identifiant ou fournisseur serait décisive.
- Encoder les données non fiables pour leur contexte exact HTML, attribut, URL, JavaScript, CSS ou DOM et utiliser une désinfection validée lorsque le balisage créé par l’utilisateur est intentionnellement supporté.
- Éviter les sinks dangereux et le code construit par concaténation de chaînes, appliquer une politique de contenu restrictive en défense en profondeur, et tester les chemins stockés, réfléchis, DOM, template, SVG et contenu enrichi.
Directives de mise en œuvre
- Modéliser les chemins normaux, de rejeu, d’énumération, cross-tenant, d’automatisation et de dépendance dégradée avant la revue de mise en œuvre.
- Modéliser les entrées, sorties, acteurs, états, invariants, effets secondaires et preuves XSS avant de sélectionner les détails du framework ou fournisseur.
- Stocker la version applicable du contrat ou de la politique XSS avec l’état matériel pour 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 voie de récupération testée jusqu’à ce que les preuves d’adoption soient complètes.
Gestion des échecs et sauvegardes
- La dégradation du contrôle préserve la frontière protégée, déclenche un signal d’incident maîtrisé, et ne donne jamais accès uniquement pour maintenir la disponibilité.
- L’état XSS invalide ou contradictoire est rejeté ou mis en quarantaine ; l’implémentation ne devine jamais une valeur élargissant l’autorité ou dupliquant 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
- Utiliser des cas appariés d’autorisation et de refus à chaque frontière de confiance et confirmer que la perte de la dépendance de contrôle échoue fermé.
- Surveiller le succès XSS, le refus, l’échec de validation, l’échec de dépendance, l’épuisement des tentatives et la récupération par version de contrat sans dimensions de charge sensible.
- Relancer les fixtures positives et négatives appariées après changement 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 universelles ; les adoptants les remplacent par des preuves documentées et une responsabilité.
- Le système adoptant peut fournir une identité authentifiée, des versions durables d’opérations ou d’enregistrements, une télémétrie bornée et un chemin contrôlé pour les changements.
Les exemples à l’apparence exécutable dans ce package sont des fixtures et 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.