Qu'est-ce que Content Security Policy (CSP) ?

Content Security Policy est un en-tête de réponse HTTP qui indique au navigateur quelles ressources sont autorisées à se charger sur la page web. Il prévient les attaques par cross-site scripting (XSS), le clickjacking et autres attaques par injection de code en limitant les sources de scripts, styles, images et autres ressources. Sans CSP, le navigateur charge toute ressource référencée dans la page, y compris les scripts malveillants injectés par un attaquant.

Quelle est la différence entre le mode rapport uniquement et le mode application ?

Content-Security-Policy-Report-Only envoie des rapports de violation mais ne bloque aucune ressource, idéal pour les tests de sécurité. Content-Security-Policy applique la stratégie et bloque les violations. Commencez toujours par le mode rapport uniquement pour identifier toutes les ressources légitimes dont la page a besoin, puis passez au mode application.

CSP peut-il remplacer la validation des entrées ?

Non. CSP est une couche de défense en profondeur et ne remplace pas la validation des entrées et l'encodage des sorties. Vous devez toujours assainir toutes les entrées utilisateur, échapper les sorties et suivre les pratiques de codage sécurisé. CSP fournit un filet de sécurité supplémentaire qui limite les dommages lorsqu'une vulnérabilité XSS est découverte, mais il ne devrait pas être votre seule ligne de défense.

Comment tester CSP avant de l'appliquer ?

Utilisez Content-Security-Policy-Report-Only pour tester votre stratégie sans casser le site. Configurez un endpoint report-uri pour collecter les rapports de violation. Surveillez les rapports pendant une période suffisamment longue (jours ou semaines) pour identifier toutes les ressources légitimes. Corrigez toute violation en ajoutant les sources nécessaires à la stratégie. Une fois qu'aucune violation légitime n'apparaît plus, passez à l'en-tête d'application.

CSP peut-il casser mon site ?

Oui, un CSP mal configuré peut bloquer des ressources légitimes, causant des fonctionnalités cassées, des images manquantes, des appels API échoués et des scripts non fonctionnels. C'est pourquoi vous devriez toujours tester d'abord en mode rapport uniquement, puis resserrer progressivement la stratégie. Utiliser 'unsafe-inline' ou 'unsafe-eval' affaiblit la protection, mais peut être nécessaire pour les applications héritées.

Guide de Content Security Policy (CSP) : protégez votre site

Les attaques par cross-site scripting (XSS) restent l'une des vulnérabilités web les plus répandues, figurant constamment dans le Top 10 OWASP. Malgré des décennies de sensibilisation à la sécurité, les attaques XSS continuent de compromettre des sites web car les défenses traditionnelles comme la validation des entrées et l'encodage des sorties ne sont pas infaillibles. Content Security Policy (CSP) offre une couche de défense supplémentaire puissante en indiquant au navigateur quelles ressources sont autorisées à se charger et à s'exécuter sur la page. Correctement configuré, CSP peut neutraliser complètement les attaques XSS en empêchant l'exécution de scripts non autorisés. Ce guide couvre tout, de la compréhension des directives à la construction et au déploiement de stratégies prêtes pour la production.

Qu'est-ce que Content Security Policy ?

Content Security Policy est un en-tête de réponse HTTP (ou une balise meta) qui permet aux opérateurs de sites de déclarer les sources de contenu approuvées que le navigateur peut charger. Il fonctionne comme une liste blanche : toute ressource non explicitement autorisée par la stratégie est bloquée. Ce mécanisme empêche les attaquants d'injecter des scripts, des styles ou d'autres ressources malveillants dans votre page, même s'ils trouvent un moyen d'insérer du HTML dans l'application.