Politique de Sécurité du Contenu
Une Politique de Sécurité du Contenu (CSP) est une norme de sécurité du navigateur définie par le World Wide Web Consortium (W3C). Elle aide les développeurs à protéger les sites web contre les attaques côté client telles que le cross-site scripting (XSS) et l’injection de données. En spécifiant des sources de confiance pour les scripts, les styles et les médias, une CSP agit comme une liste blanche que les navigateurs appliquent automatiquement dans le cadre du modèle de sécurité côté client du navigateur.
Résumé (TL;DR)
- La CSP définit quelles sources un navigateur peut faire confiance.
- Elle aide à bloquer les scripts injectés ou non autorisés.
- Elle réduit les risques de XSS et d’exfiltration de données.
- Meilleure utilisation avec la validation des entrées et HTTPS.
- Nécessite une maintenance et des tests continus.
Comprendre la Politique de Sécurité du Contenu (CSP)
La Politique de Sécurité du Contenu (CSP) est une fonctionnalité de sécurité du navigateur qui a été mise en œuvre pour atténuer certains types d’attaques basées sur le navigateur, comme le cross-site scripting. La CSP a été standardisée par le World Wide Web Consortium (W3C) dans la spécification CSP Level 3, elle permet à un site web d’envoyer un ensemble de règles (via des en-têtes de réponse HTTP ou des balises à l’intérieur du HTML) qui indiquent au navigateur quelles sources de contenu sont autorisées.
Ces règles, appelées directives, spécifient les origines approuvées pour les scripts, les images, les styles, les iframes et plus encore. L’objectif principal de l’utilisation de CSP est d’avoir un contrôle total sur l’origine des scripts chargés, ainsi que de contrôler quels scripts une page est autorisée à exécuter, tentant ainsi d’empêcher l’exécution de scripts injectés ou non autorisés.
Par exemple, une directive CSP pourrait indiquer que les scripts ne doivent être chargés que depuis le propre domaine du site (fait en utilisant ‘self’), ou depuis des domaines de confiance spécifiques. Le navigateur bloquera alors tout fichier de script ou script inline qui n’est pas d’une source autorisée, fournissant une défense cruciale contre les attaques XSS où un attaquant tente d’injecter des balises
Comment fonctionne la Politique de Sécurité du Contenu (CSP)
Une Politique de Sécurité du Contenu est livrée à un navigateur via l’en-tête de réponse HTTP nommé `Content-Security-Policy`, ou via une balise meta dans le HTML. La politique consiste en directives séparées par des points-virgules, et chaque directive contrôle un type de ressource spécifique.
- ‘script-src’ self : permet les scripts uniquement depuis la même origine. Tout
- ‘connect-src’ self https://api.domain.com : permet les appels AJAX/XHR/fetch uniquement vers le même site, ou vers le domaine de confiance api.domain.com. Cela empêche le code malveillant d’exfiltrer des données vers des serveurs inconnus depuis le site.
- img-src ‘self’ data : peut être utilisé pour charger uniquement des images depuis le même site et bloquer les images externes, ce qui peut être utilisé pour empêcher les fuites de données via les requêtes d’image.
Nonces CSP et Hashes CSP
CSP prend également en charge des mécanismes avancés tels que les nonces (‘nonce-abc123’) et les hashes (‘sha256-xyz…’). Ceux-ci permettent aux scripts inline de s’exécuter en toute sécurité en prouvant cryptographiquement leur intégrité. Au lieu d’interdire tout le code inline, les développeurs peuvent autoriser sélectivement des scripts spécifiques, améliorant la flexibilité sans sacrifier la sécurité.
Il existe une multitude d’autres directives qui peuvent être utilisées pour d’autres types de données comme les médias, les polices, les iframes, etc., mais l’idée centrale de l’utilisation d’une Politique de Sécurité du Contenu est de créer une liste blanche de sources de confiance. Lorsque le navigateur charge une page et demande quel contenu charger, il se référera d’abord à la CSP et appliquera ces règles à chaque chargement. Tout script ou ressource qui charge cette politique ne sera pas chargé. Pour un guide d’implémentation détaillé, consultez la feuille de référence OWASP CSP.
Directives CSP Courantes et Leur Objectif
| Directive | Objectif | Cas d’Usage Typique |
|---|---|---|
default-src | Définit une politique de base pour toutes les ressources lorsqu’aucune autre règle ne s’applique. | Commencez strict : default-src 'none'; |
script-src | Contrôle quelles sources JavaScript sont autorisées. | Liste blanche 'self', CDN, ou utilisez des scripts basés sur nonce/hash. |
style-src | Limite d’où CSS peut être chargé. | Utilisez 'self' ; évitez 'unsafe-inline' lorsque possible. |
img-src | Définit les sources d’image de confiance. | Empêchez les fuites de données via les appels d’image externes. |
connect-src | Restreint les destinations AJAX, fetch et WebSocket. | Bloquez l’exfiltration de données vers des domaines inconnus. |
frame-ancestors | Spécifie quels sites peuvent intégrer vos pages dans des iframes. | Empêchez le clickjacking : frame-ancestors 'none'; |
report-uri / report-to | Définit où les rapports de violation CSP sont envoyés. | Enregistrez et analysez les violations CSP pour ajuster la politique. |
Comment une CSP peut Protéger un Site Web
Atténuation des attaques XSS : Dans une attaque de cross-site scripting, ou attaque XSS, un attaquant trouve généralement un moyen d’injecter et d’exécuter du code JavaScript malveillant dans votre page (comme sur une entrée non assainie). Par défaut, une CSP bloquera tout script inline de s’exécuter sur la page, sauf si une directive de politique l’autorise explicitement. Cela signifie qu’un attaquant qui injecte quelque chose comme `` dans une page, cela ne s’exécutera pas (sauf si ‘unsafe-inline’ est désactivé dans la CSP !)
Blocage des scripts tiers non autorisés : De nombreux sites ont des scripts tiers pour des choses comme l’analyse, le suivi des utilisateurs et la publicité. Avec une CSP, les propriétaires de sites peuvent limiter quels sites externes peuvent réellement fournir des scripts. Par exemple, si vous ne cherchez qu’à servir du contenu depuis `analytics.example.com` et rien d’autre depuis example.com, la directive script-src CSP de votre site peut explicitement autoriser uniquement cela.
Prévention de l’exfiltration de données : Comme mentionné précédemment, une CSP peut restreindre les actions sur une page qui peuvent être utilisées pour empêcher le code JavaScript malveillant d’envoyer des données vers un domaine contrôlé par un attaquant. L’utilisation de la directive `connect-src` bloque les requêtes réseau vers des serveurs non autorisés, et peut être utilisée en combinaison avec la directive `form-action` pour s’assurer que les données ne sont envoyées qu’à votre domaine.
Appliquer des pratiques de navigation sécurisées : Une CSP a des directives pour appliquer des comportements sécurisés qui améliorent la sécurité de votre site en général. Un exemple de cela est `upgrade-insecure-requests`, qui force le navigateur à charger toutes les ressources via HTTPS, empêchant les problèmes de contenu mixte et non sécurisé. Une autre directive est `frame-ancestors`, qui peut empêcher les attaques de clickjacking en interdisant l’intégration de votre page dans un cadre contrôlé par un attaquant.
Comment CSP Prévient les Attaques Basées sur le Navigateur
1. Atténuation des attaques XSS :
Dans une attaque de cross-site scripting, ou attaque XSS, un attaquant trouve généralement un moyen d’injecter et d’exécuter du code JavaScript malveillant dans votre page (comme sur une entrée non assainie). Par défaut, une CSP bloquera tout script inline de s’exécuter sur la page, sauf si une directive de politique l’autorise explicitement. Cela signifie qu’un attaquant qui injecte quelque chose comme `` dans une page, cela ne s’exécutera pas (sauf si ‘unsafe-inline’ est désactivé dans la CSP !)
2. Blocage des scripts tiers non autorisés :
De nombreux sites ont des scripts tiers pour des choses comme l’analyse, le suivi des utilisateurs et la publicité. Avec une CSP, les propriétaires de sites peuvent limiter quels sites externes peuvent réellement fournir des scripts. Par exemple, si vous ne cherchez qu’à servir du contenu depuis `analytics.example.com` et rien d’autre depuis example.com, la directive script-src CSP de votre site peut explicitement autoriser uniquement cela.
3. Prévention de l’exfiltration de données :
Comme mentionné précédemment, une CSP peut restreindre les actions sur une page qui peuvent être utilisées pour empêcher le code JavaScript malveillant d’envoyer des données vers un domaine contrôlé par un attaquant. L’utilisation de la directive `connect-src` bloque les requêtes réseau vers des serveurs non autorisés, et peut être utilisée en combinaison avec la directive `form-action` pour s’assurer que les données ne sont envoyées qu’à votre domaine.
4. Appliquer des pratiques de navigation sécurisées :
Une CSP a des directives pour appliquer des comportements sécurisés qui améliorent la sécurité de votre site en général.
- Un exemple de cela est `upgrade-insecure-requests`, qui force le navigateur à charger toutes les ressources via HTTPS, empêchant les problèmes de contenu mixte et non sécurisé.
- Une autre directive est `frame-ancestors`, qui peut empêcher les attaques de clickjacking en interdisant l’intégration de votre page dans un cadre contrôlé par un attaquant.
Combinées, ces politiques aboutissent à une base solide côté client pour les applications web modernes.
Limitations de Sécurité de CSP
L’utilisation d’une Politique de Sécurité du Contenu fournit une protection forte mais ce n’est pas une solution universelle pour votre site, comme le souligne notre article “Pourquoi la Politique de Sécurité du Contenu ne fonctionne pas”.
Les politiques peuvent dériver au fil du temps, et les listes blanches n’inspectent pas le comportement du code. Chaque navigateur majeur implémente CSP à sa manière, légèrement différente. Chrome, Firefox, Safari et Edge prennent tous en charge CSP Level 3 ; le comportement de rapport et les formats de violation peuvent varier. Pour valider et maintenir votre politique, testez-la régulièrement avec les outils de développement du navigateur et les scanners automatisés tels que Mozilla Observatory ou SecurityHeaders.io.
Associer une CSP avec un proxy côté client actif comme cside pour ajouter une inspection et un blocage en temps réel aux scripts tiers sur votre site vous donne une excellente couche de défense, avec la tranquillité d’esprit pour vos clients. D’un point de vue de gouvernance, documenter les mises à jour CSP et surveiller les rapports de violation améliore l’auditabilité et la conformité à long terme avec des cadres tels que ISO 27001 et OWASP ASVS.
Est-ce que CSP Fonctionne pour la Conformité PCI DSS 6.4.3 ?
Sous l’exigence 6.4.3 de PCI DSS 4.0.1, les commerçants doivent prouver que chaque script côté client est autorisé et prouver l’intégrité du script. CSP et SRI vous mènent en partie là. CSP limite quels domaines peuvent charger des scripts, et SRI vérifie que le code d’un fichier n’a pas changé. Mais ensemble, ils sont une solution statique à un problème dynamique. Les scripts dynamiques se mettent à jour et les hashes se cassent. La maintenance manuelle des listes CSP est presque impossible.
La plupart des sites modernes utilisent des scripts tiers dynamiques, donc ces contrôles se dégradent rapidement. Cette approche ne répondra généralement pas aux preuves requises nécessaires pour PCI 6.4.3.
Un Exemple d’une CSP Mal Configurée
Le jour où le check-out a cessé de fonctionner : Comment une CSP Stricte a Cassé la Production
Tout a commencé avec un simple nouveau déploiement. Rien de spécial, juste une nouvelle Politique de Sécurité du Contenu pour rendre une boutique de commerce électronique plus sécurisée et bloquer les attaquants de s’introduire avec du mauvais code.
Le default-src ‘none’ propre a été défini sans test. Et donc, au moment où la CSP a été activée, le site web a bloqué les services dont il avait réellement besoin. L’analyse a cessé de fonctionner et le pire de tout, le système de paiement a été bloqué. Les clients ne pouvaient pas compléter leurs commandes et le système de check-out s’est cassé. Les développeurs se sont mis au travail et ont changé l’en-tête en Content-Security-Policy-Report-Only et ont collecté les journaux de violation. À partir de là, ils ont construit une liste blanche (script-src ‘self’ https://pay.examplecase.com) avec tous les services dont la boutique web avait besoin pour fonctionner correctement.
Affiner la CSP a permis le déploiement sans interruption. Malheureusement, cette négligence est un accident courant lorsque les équipes gèrent CSP en interne. Oublier de mettre sur liste blanche un nouveau script marketing, des configurations techniques incorrectes, ou des problèmes avec des scripts dynamiques qui cassent les protocoles de hachage font de CSP un cauchemar à gérer à l’échelle.
