Content Security Policy (CSP) sans casser votre site
Vous avez entendu dire que la Content Security Policy (CSP) est essentielle pour protéger votre site contre les attaques de cross-site scripting (XSS) et d'injection de données. Mais lorsque vous essayez de l'ajouter, votre site casse : les images disparaissent, les scripts ne s'exécutent plus, les styles s'évanouissent. On a l'impression de devoir choisir entre sécurité et fonctionnalité. Ce n'est pas une fatalité.
Dans ce guide, vous apprendrez une approche pratique, étape par étape, pour déployer CSP sans casser votre site. Nous couvrirons les directives principales, comment utiliser les nonces et les hashs, et comment tester en toute sécurité. À la fin, vous aurez une CSP fonctionnelle qui améliore la sécurité sans sacrifier l'expérience utilisateur.
Qu'est-ce que CSP et pourquoi casse-t-elle les sites ?
Content Security Policy est une norme de sécurité des navigateurs qui vous permet de restreindre les ressources (scripts, styles, images, polices, etc.) qui peuvent être chargées sur votre page. Elle est transmise via un en-tête HTTP comme Content-Security-Policy: default-src 'self'.
CSP casse les sites car elle bloque toute ressource qui ne correspond pas à votre politique. Si vous avez des scripts inline, des scripts externes depuis des CDN, ou des styles inline, ils seront bloqués à moins que vous ne les autorisiez explicitement. Le comportement par défaut est de bloquer tout ce qui n'est pas autorisé, c'est pourquoi une politique stricte peut rapidement casser un site.
La clé est de commencer par une politique permissive et de la resserrer progressivement tout en surveillant les violations.
Directives CSP essentielles à connaître
CSP utilise des directives pour contrôler différents types de ressources. Voici les plus courantes :
- default-src : Fallback pour les autres directives. Commencez ici.
- script-src : Contrôle les sources JavaScript.
- style-src : Contrôle les sources CSS.
- img-src : Contrôle les sources d'images.
- connect-src : Contrôle les cibles AJAX, WebSocket et fetch.
- font-src : Contrôle les sources de polices web.
- frame-src : Contrôle les sources d'iframes.
- report-uri / report-to : Où envoyer les rapports de violation.
Vous pouvez définir plusieurs directives dans un seul en-tête, séparées par des points-virgules. Par exemple :
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.comChaque directive accepte une liste de sources séparées par des espaces. Les sources peuvent être des mots-clés comme 'self', 'unsafe-inline', 'unsafe-eval', ou des URL, ou des nonces/hashs.
Étape par étape : déployer CSP sans casser votre site
Suivez ces étapes pour déployer CSP en toute sécurité.
- Commencez par une politique en mode rapport uniquement. Utilisez l'en-tête
Content-Security-Policy-Report-Onlyau lieu de celui qui applique la politique. Cela vous permet de voir ce qui serait bloqué sans réellement le bloquer. - Définissez une politique permissive. Commencez par quelque chose comme
default-src 'self' 'unsafe-inline' 'unsafe-eval' https:pour tout autoriser. Cela minimise les cassures. - Collectez les rapports de violation. Configurez
report-urivers un endpoint qui enregistre les violations. Examinez ces rapports pour identifier les ressources bloquées. - Corrigez les violations. Mettez à jour votre code pour éviter les scripts/styles inline, ou ajoutez des nonces/hashs. Déplacez les ressources externes vers des domaines autorisés.
- Resserrez la politique progressivement. Supprimez
'unsafe-inline'et'unsafe-eval'une fois que vous avez refactorisé. Restreignez les domaines autorisés. - Passez en mode application. Une fois que les rapports ne montrent plus de blocages inattendus, changez l'en-tête en
Content-Security-Policy(sans-Report-Only). - Surveillez en continu. Gardez l'endpoint de rapport actif pour détecter de nouveaux problèmes.
Cette approche incrémentale garantit que vous ne cassez pas votre site tout en améliorant la sécurité.
Utilisation des nonces et des hashs pour les scripts inline
Les scripts inline sont une cause fréquente de rupture de CSP. Au lieu d'autoriser 'unsafe-inline', utilisez un nonce (numéro utilisé une fois) ou un hash.
Approche par nonce : Générez un nonce aléatoire par requête, ajoutez-le à votre en-tête CSP et incluez-le dans vos balises script.
Content-Security-Policy: script-src 'nonce-abc123'<script nonce="abc123">...</script>Approche par hash : Calculez le hash SHA de votre script inline et ajoutez-le à la politique.
Content-Security-Policy: script-src 'sha256-xyz...'Les hashs sont préférables pour les scripts inline statiques qui ne changent pas souvent. Les nonces sont meilleurs pour le contenu dynamique.
Pour les styles, vous pouvez également utiliser des nonces ou des hashs, mais notez que style-src avec des nonces ne couvre pas les attributs de style inline (par exemple, style="..."). Pour ceux-ci, vous avez besoin de 'unsafe-inline' ou de refactoriser en classes.
Directives CSP courantes et leur impact
| Directive | Ce qu'elle contrôle | Sources courantes |
|---|---|---|
| default-src | Fallback pour tous les types de ressources | 'self', https: |
| script-src | Sources JavaScript | 'self', 'nonce-...', 'sha256-...', https://cdn.com |
| style-src | Sources CSS | 'self', 'unsafe-inline', 'nonce-...' |
| img-src | Sources d'images | 'self', data:, https://images.com |
| connect-src | AJAX, WebSocket, fetch | 'self', https://api.com |
| font-src | Polices web | 'self', https://fonts.gstatic.com |
| frame-src | Iframes | 'self', https://youtube.com |
Utilisez ce tableau comme référence rapide lors de la construction de votre politique.
Tester et surveiller votre CSP
Avant d'appliquer, testez minutieusement. Utilisez les outils de développement du navigateur : l'onglet Console affiche les violations CSP sous forme d'erreurs. L'onglet Réseau montre l'en-tête CSP.
Pour les tests automatisés, envisagez des outils comme le CSP Evaluator de Google (en ligne) ou le package npm csp_evaluator. Ils aident à identifier les politiques faibles.
Configurez un endpoint de rapport pour collecter les violations en production. Vous pouvez utiliser un service comme Report URI ou créer votre propre endpoint qui enregistre dans un fichier ou une base de données. Analysez régulièrement les rapports pour détecter de nouveaux problèmes.
Rappelez-vous : CSP n'est pas une solution miracle. C'est une couche de défense. Combinez-la avec la validation des entrées, l'encodage des sorties et d'autres bonnes pratiques de sécurité.
FAQ
Quelle est la différence entre Content-Security-Policy et Content-Security-Policy-Report-Only ?
L'en-tête d'application (Content-Security-Policy) bloque les violations. L'en-tête de rapport uniquement (Content-Security-Policy-Report-Only) ne fait que signaler les violations sans les bloquer, ce qui vous permet de tester une politique en toute sécurité.
Puis-je utiliser CSP avec des gestionnaires d'événements inline comme onclick ?
Non, les gestionnaires d'événements inline sont bloqués par CSP à moins d'utiliser 'unsafe-inline' (ce qui est déconseillé) ou de refactoriser pour utiliser addEventListener. Pour une meilleure sécurité, évitez les gestionnaires d'événements inline.
Comment autoriser Google Analytics avec CSP ?
Ajoutez les domaines Google Analytics à vos directives script-src et connect-src. Par exemple : script-src 'self' https://www.googletagmanager.com; connect-src 'self' https://www.google-analytics.com. Consultez la documentation de Google pour les dernières exigences.
Déployer CSP ne doit pas être un processus douloureux. Avec une approche progressive, vous pouvez protéger vos utilisateurs contre les XSS et autres attaques sans perturber votre site. Commencez par le mode rapport uniquement, corrigez les violations et resserrez votre politique au fil du temps.
Si vous avez besoin de formater ou valider rapidement des fichiers de configuration JSON pour vos rapports CSP, essayez notre JSON Formatter pour embellir et déboguer vos données JSON.