INSTRUCTIONS AU MODÈLE - Répondre sans outil externe ni Internet. - Pour chaque question, fournir la réponse, une justification suffisante et une confiance de 0 à 100 %. - Ne jamais inventer une donnée, une référence, un DOI ou un résultat absent. - Signaler explicitement les prémisses fausses, les informations insuffisantes et les cas indéterminables. - Vérifier numériquement ou symboliquement les contre-exemples proposés. - Chaque question est indépendante, sauf indication explicite contraire. Q095 — Une CSP HTTP (Content-Security-Policy) correctement configurée peut-elle réduire l’impact des XSS ? Peut-elle remplacer l’encodage contextuel ?
Oui, une CSP correctement configurée peut réduire significativement l’impact des XSS, mais elle ne peut pas remplacer l’encodage contextuel. Une CSP agit comme une couche de défense en profondeur. Elle ne supprime pas la vulnérabilité elle-même, mais elle limite ce qu’un attaquant peut faire une fois qu’un script malveillant a réussi à s’exécuter. Concrètement, une politique stricte comme `default-src 'self'` ou `script-src 'self'` empêche l’exécution de scripts inline et de scripts provenant de domaines tiers, ce qui neutralise la plupart des payloads XSS classiques, notamment les balises `<script>`, les gestionnaires d’événements inline et les URLs `javascript:`. C’est pourquoi la CSP est considérée comme un contrepoids efficace : elle réduit la surface d’exploitation et la portée des dégâts. Cependant, elle ne peut pas remplacer l’encodage contextuel, et ce pour plusieurs raisons. D’abord, la CSP n’est pas une garantie absolue. Des failles de contournement ont été documentées, par exemple via des gadgets de type JSONP sur des domaines autorisés, ou des injections dans des attributs non couverts par la politique. Une politique trop permissive, ou mal écrite, peut laisser passer des vecteurs d’attaque. Ensuite, et c’est le point décisif, la CSP ne traite pas la cause du XSS. L’encodage contextuel, lui, s’applique au point d’émission : il transforme les données utilisateur selon le contexte précis où elles sont insérées, qu’il s’agisse de HTML, d’un attribut, de JavaScript, de CSS ou d’une URL, de sorte que les caractères dangereux ne puissent jamais être interprétés comme du code. C’est la seule mesure qui rend l’injection structurellement impossible, indépendamment de la politique de sécurité. Enfin, la CSP ne couvre pas tous les contextes d’injection. Par exemple, une injection dans un attribut `href` ou dans un contexte CSS peut parfois échapper à la politique. L’encodage contextuel, lui, est exhaustif par construction. La CSP est donc un complément précieux, voire indispensable, mais elle relève de la défense en profondeur. L’encodage contextuel reste la défense primaire et non négociable contre les XSS. Les deux mesures sont complémentaires, jamais substituables. Confiance : 92 %. Cette réponse repose sur des principes de sécurité web bien établis et documentés, notamment par l’OWASP et les recommandations du W3C sur la CSP. La confiance n’est pas à 100 % car je ne peux pas vérifier ici chaque cas de contournement historique ni chaque nuance des spécifications, mais le fondement conceptuel, à savoir la CSP comme mesure de mitigation et non de prévention structurelle, est solidement établi.
Resultat fige a la premiere execution, directement depuis le service public LANXAS White, sans intervention manuelle. Cette page est permanente et peut etre re-consultee pour verification.