flawopen.com/XSS/CSP vs. escape
CSP et échappement de sortie : les deux sont-ils nécessaires ?
L’encodage contextuel place les valeurs non fiables dans la page comme des données, pas comme du balisage exécutable. Une Content Security Policy (CSP) est une seconde barrière : tel un gardien qui vérifie quels scripts peuvent s’exécuter et où ils peuvent se connecter, elle peut bloquer certains comportements injectés si l’encodage a été oublié. Elle ne corrige pas la faille et une politique permissive peut laisser le script s’exécuter.
Rôle de chaque protection
Encodez les données au moment où elles entrent dans le contexte de sortie. Le texte HTML, les attributs entre guillemets, JavaScript, CSS et les composants d’URL ont des règles d’analyse différentes ; l’encodeur dépend du contexte exact. Préférez les templates du framework et les sinks DOM sûrs, et évitez les contextes exécutables comme les scripts inline et attributs d’événement. C’est la défense principale contre les XSS.
Une Content-Security-Policy appliquée peut restreindre les scripts inline, les sources de script et les destinations comme connect-src. Si l’encodage échoue, une politique bien conçue peut bloquer un script ou une connexion précise. Le résultat dépend de la politique et du navigateur : CSP ne garantit pas de bloquer tout payload, toute fuite de données ou tout script gadget ; l’injection demeure.
Pourquoi CSP ne remplace pas l’encodage de sortie
Une politique permissive ou mal configurée peut laisser l’injection exécutable. Autoriser 'unsafe-inline' affaiblit la protection contre les scripts inline ; une liste large d’hôtes peut aussi accepter des points de terminaison capables de fournir des scripts. Les directives ont des rôles distincts : restreindre script-src peut nécessiter un connect-src réfléchi pour limiter les destinations réseau. Content-Security-Policy-Report-Only signale les violations mais ne les bloque pas. Corrigez avec l’encodage et ajoutez CSP en défense en profondeur.
Questions fréquentes
Inventoriez les scripts nécessaires et testez une politique fondée sur des nonces ou des hachages, sans 'unsafe-inline' ni 'unsafe-eval'. Utilisez Content-Security-Policy-Report-Only pour repérer les incompatibilités ; elle n’applique pas la politique. Examinez les rapports, corrigez les dépendances légitimes puis déployez une Content-Security-Policy appliquée. Gardez l’encodage contextuel pendant tout le déploiement.
Références
- OWASP — guide Content Security Policy
- OWASP — prévention du Cross-Site Scripting
- MDN — mise en œuvre de Content Security Policy
- W3C — Content Security Policy Level 3