Introduction 

Dans le monde numérique d’aujourd’hui, la sécurité des sites web est primordiale. Une des meilleures pratiques pour renforcer cette sécurité est l’utilisation d’une Content Security Policy (CSP). Mais qu’est-ce qu’une CSP exactement, et pourquoi est-elle si importante ? 

Qu’est-ce qu’une Content Security Policy ? 

Une Content Security Policy est un mécanisme de sécurité qui permet aux propriétaires de sites web de contrôler précisément quelles ressources peuvent être chargées et exécutées sur leurs pages. En d’autres termes, c’est comme un gardien qui décide quels contenus sont autorisés à entrer sur votre site. 

Pourquoi ajouter des CSP ? 

Sans CSP, votre site web est plus vulnérable à diverses attaques, notamment : 

  • Cross-Site Scripting (XSS) : Des attaquants peuvent injecter des scripts malveillants dans vos pages. 
  • Injection de données : Des contenus non autorisés peuvent être insérés dans votre site. 
  • Clickjacking : Votre site peut être afficher sur un autre site malveillant pour tromper les utilisateurs 

Ces vulnérabilités peuvent conduire au vol de données sensibles, à la manipulation du contenu de votre site, ou même à la distribution de malwares. 

Cross-Site Scripting (XSS) 

Risque : Un attaquant injecte un script malveillant dans votre site pour voler des informations sensibles ou manipuler le comportement de votre application. 

Exemple : Supposons que votre site permet aux utilisateurs de poster des messages avec des balises HTML. Si un attaquant poste un message contenant un script malveillant comme suit : 

<script>alert('Vous avez été piraté !');</script> 

Si votre site n’a pas de CSP ou si elle autorise les scripts inline via unsafe-inline, ce script sera exécuté par le navigateur des utilisateurs qui visitent la page, permettant à l’attaquant d’exécuter du code arbitraire. 

Avec les CSP : Utilisez des nonces ou des hashes pour autoriser uniquement les scripts légitimes. 

Injection de données 

Risque : Des contenus non autorisés peuvent être insérés dans votre site, modifiant son comportement ou apparence. 

Exemple : Un attaquant injecte une balise <style> pour modifier l’apparence de votre site ou une balise <img> pour afficher des images non autorisées. 

Avec les CSP : Limitez les sources autorisées pour les styles et les images. 

Content-Security-Policy: style-src 'self'; img-src 'self' https://trusted-cdn.com; 

Clickjacking 

Risque : Un attaquant superpose une couche invisible de son site sur le vôtre pour tromper les utilisateurs et les amener à effectuer des actions involontaires. 

Exemple : Un attaquant intègre votre site dans une iframe (visible) et superpose son propre contenu. Lorsqu’un utilisateur clique sur cette page, il a l’impression de cliquer sur un bouton de votre site, mais en réalité clique sur le site de l’attaquant.

Mitigation avec CSP : Utilisez le header Content-Security-Policy avec la directive frame-ancestors pour contrôler qui peut intégrer votre site dans une iframe. 

Content-Security-Policy: frame-ancestors 'self'; 

Comment implémenter une CSP efficacement 

La mise en place d’une CSP peut sembler complexe, mais voici les étapes essentielles : 

  • Définir votre politique : Commencez par identifier les sources de contenu légitimes pour votre site. 
  • Utiliser le mode rapport : Avant d’appliquer strictement votre CSP, utilisez le header Content-Security-Policy-Report-Only pour identifier les problèmes potentiels sans bloquer le contenu. 
  • Appliquer la politique : Une fois que vous êtes sûr que votre CSP n’interfère pas avec le fonctionnement normal de votre site, implémentez-la via le header HTTP Content-Security-Policy. 
  • Affiner progressivement : Commencez avec une politique de base et renforcez-la progressivement. 

Voici un exemple de CSP de base : 

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; 

Cette politique autorise le chargement de ressources uniquement depuis votre propre domaine, avec des scripts supplémentaires autorisés depuis un CDN de confiance. 

Comparaison des directives CSP 

Lorsque vous configurez une CSP, vous avez plusieurs options pour spécifier les sources autorisées. Voici une brève comparaison entre quelques-unes des directives les plus courantes : 

  • Nonce : Un nonce est un jeton aléatoire généré pour chaque requête. Il est utilisé pour autoriser des scripts inline tout en évitant les attaques XSS. Le nonce doit être inclus dans le script et dans la politique CSP. 
  • Hash : Un hash est une empreinte numérique unique générée à partir du contenu d’un script. Il permet d’autoriser des scripts inline spécifiques sans compromettre la sécurité. 
  • Domaine : Spécifier un domaine (par exemple, https://example.com) autorise le chargement de ressources depuis ce domaine. 
  • ‘self’ : Cette directive permet de charger des ressources depuis le même domaine que le site actuel. 
  • ‘unsafe’ : Les directives comme unsafe-inline ou unsafe-eval permettent respectivement l’exécution de scripts inline ou l’utilisation de eval(), mais elles affaiblissent considérablement la sécurité de votre site. 

Catégories de configuration CSP 

Voici une liste des principales catégories de configuration CSP et leur rôle : 

  • default-src : Définit la source par défaut pour tous les types de ressources si elles ne sont pas spécifiées explicitement. 
  • script-src : Contrôle les sources autorisées pour les scripts. 
  • style-src : Contrôle les sources autorisées pour les feuilles de style. 
  • img-src : Contrôle les sources autorisées pour les images. 
  • font-src : Contrôle les sources autorisées pour les polices de caractères. 
  • connect-src : Contrôle les sources autorisées pour les requêtes XHR et WebSocket. 
  • frame-src : Contrôle les sources autorisées pour les iframes. 
  • child-src : Contrôle les sources autorisées pour les iframes et les workers web. 
  • object-src : Contrôle les sources autorisées pour les objets incorporés. 
  • media-src : Contrôle les sources autorisées pour les médias (vidéos, audio). 
  • frame-ancestors : Contrôle qui peut intégrer votre site dans une iframe. 

Détails sur les nonces et les hashes 

Nonces 

Un nonce est un jeton aléatoire généré pour chaque requête. Voici comment il fonctionne : 

  • Génération du nonce : Le serveur génère un nonce aléatoire pour chaque page chargée. 
  • Inclusion dans le script : Le nonce est inclus dans chaque script inline comme attribut. 
  • Définition dans la CSP : Le même nonce est spécifié dans la politique CSP pour autoriser ces scripts. 

Exemple de code avec un nonce : 

<script nonce="random_nonce_value">...</script> 

Et dans la CSP : 

Content-Security-Policy: script-src 'self' 'nonce-random_nonce_value'; 

Hashes 

Un hash est une empreinte numérique unique générée à partir du contenu d’un script. Attention, si votre script change, le hash change également. Voici comment il fonctionne : 

  • Génération du hash : Un hash est généré à partir du contenu d’un script inline. 
  • Inclusion dans la CSP : Le hash est spécifié dans la politique CSP pour autoriser ce script. 

Exemple de code avec un hash : 

<script>console.log('Hello World!');</script> 

Le hash SHA-256 de ce script est sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=. Dans la CSP : 

Content-Security-Policy: script-src 'self' 'sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='; 

Être alerté en cas de problème

Il est crucial de savoir quand votre CSP bloque des ressources. Pour cela, vous pouvez configurer la directive report-to (qui remplace report-uri, bien que ce dernier soit toujours pris en charge pour la compatibilité avec les anciens navigateurs). Cette directive permet d’envoyer des rapports JSON à une URL spécifiée chaque fois qu’une ressource est bloquée par votre CSP. 

Configurer l’en-tête Reporting-Endpoints : 

Définissez un en-tête Reporting-Endpoints qui spécifie les points de terminaison pour l’envoi des rapports.  

Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"

Utiliser report-to dans la CSP : 

Spécifiez le nom du groupe de rapport dans votre CSP. 

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; report-to csp-endpoint; 

Configurer un point de terminaison de rapport : 

Mettez en place un point de terminaison sur votre serveur (par exemple, /csp-report-endpoint) pour recevoir et traiter les rapports JSON. 

Bonnes pratiques pour une CSP robuste 

  • Évitez les directives « unsafe » : N’utilisez pas unsafe-inline ou unsafe-eval sauf si absolument nécessaire. 
  • Utilisez des nonces ou des hashes pour les scripts inline inévitables. 
  • Limitez l’utilisation des wildcards (*) qui peuvent affaiblir votre politique. 
  • Testez régulièrement votre CSP avec des outils comme le CSP Evaluator de Google ou mettez en place un Report-To. 

Conclusion 

L’implémentation d’une Content Security Policy est une étape cruciale pour sécuriser votre site web. Bien que cela puisse sembler complexe au début, les bénéfices en termes de sécurité sont considérables. En suivant les bonnes pratiques et en affinant progressivement votre politique, vous pouvez significativement réduire les risques d’attaques et protéger vos utilisateurs et vos données. 

N’oubliez pas que la sécurité web est un processus continu. Restez informé des dernières recommandations en matière de CSP et ajustez votre politique en conséquence. Votre site n’en sera que plus sûr et plus fiable. 

Articles recommandés pour vous