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

Le Content Security Policy (CSP) est une norme de sécurité qui a été conçue pour prévenir certaines attaques Web, notamment les injections de contenu et les attaques de type Cross Site Scripting (XSS). Il s’agit d’un moyen efficace pour les développeurs de contrôler les ressources autorisées à charger et à s’exécuter sur une page web, renforçant ainsi la sécurité du site et de ses utilisateurs.

En spécifiant une liste blanche d’origines fiables pour différentes types de ressources, le CSP sert de barrière contre l’utilisation de ressources malveillantes.

Les administrateurs de sites Web mettent en œuvre le CSP en ajoutant un en-tête HTTP spécial à leurs réponses serveur.

Cet en-tête décrit les politiques de sécurité qui doivent être appliquées par le navigateur, permettant ainsi de déterminer si une ressource doit être bloquée ou autorisée à se charger.

Le CSP offre également la possibilité de générer des rapports sur les tentatives et les violations de politique, offrant une visibilité sur les menaces potentielles et facilitant l’adaptation des règles de sécurité en conséquence.

Bien que largement supporté par les navigateurs modernes, il convient de planifier soigneusement son déploiement pour maintenir la compatibilité avec les fonctionnalités Web existantes.

Une configuration appropriée est essentielle pour tirer pleinement avantage du CSP sans perturber l’expérience utilisateur, rendant ainsi l’usage de ce mécanisme à la fois puissant et souple pour défendre les applications web contre les menaces courantes.

À lire sur le même sujet : Les différentes catégories de cyberattaques

Les points clés

• Le CSP protège contre les injections de contenu et les attaques XSS.
• Il implique l’ajout d’un en-tête HTTP pour contrôler les ressources chargées.
• Une configuration adéquate du CSP est cruciale pour l’équilibre entre sécurité et fonctionnalité.

Qu’est-ce que le CSP ?

Le Content Security Policy (CSP) est un standard conçu pour prévenir certaines attaques de sécurité liées au contenu d’un site web.

Il définit des directives claires quant aux ressources autorisées sur un serveur.

Définition et principes de base

Le CSP est défini comme un ensemble de règles qu’un propriétaire de site internet peut mettre en place pour spécifier les domaines à partir desquels les navigateurs sont autorisés à charger du contenu.

Ces règles sont conçues pour se prémunir contre des menaces telles que les attaques par injection, en particulier les attaques Cross Site Scripting (XSS).

Principaux éléments du CSP :

• Directive : une règle indiquant les origines des ressources autorisées.
• Source : une origine spécifique (par exemple, un domaine) d’où les ressources sont autorisées à être chargées.
• Politique : l’ensemble complet des directives qui forment le CSP d’un site.

Objectifs de la politique de sécurité du contenu

L’objectif primaire du CSP est d’améliorer la sécurité des sites web.

La politique vise à réduire le risque d’inclusions de contenu malveillant en établissant une liste blanche d’origines de ressources fiables.

Les navigateurs qui prennent en charge le CSP n’exécuteront ou n’afficheront que le contenu qui correspond à ces directives, améliorant ainsi la sécurité du site web.

Fonctionnement du CSP

Le Content Security Policy (CSP) est un standard de sécurité qui vise à prévenir les attaques telles que l’injection de contenu et le Cross-Site Scripting (XSS).

Il s’agit d’une série de directives transmises via l’en-tête HTTP d’une réponse, qui permettent de contrôler les ressources autorisées à charger sur une page web.

Les directives du CSP

Les directives du CSP sont des instructions qui indiquent au navigateur les types de contenus qui peuvent être exécutés ou chargés sur la page web.

Exemples courants de directives incluent script-src, qui définit les origines autorisées pour les scripts, et style-src, pour les feuilles de style CSS.

Chaque directive peut spécifier plusieurs types de sources ou comportements autorisés.

• script-src : détermine les sources valides pour les scripts JavaScript.
• style-src : indique les sources autorisées pour les feuilles de style.

Les sources validées

Les sources validées par CSP peuvent être définies de manière spécifique ou à l’aide de jokers. Elles délimitent où le navigateur peut charger les ressources.

Les sources peuvent être l’origine du document, spécifiée avec 'self', des domaines spécifiques ou des schémas comme https.

Il est également possible de permettre l’exécution de scripts inline via 'unsafe-inline' ou d’inclure des hashes pour des scripts particuliers.

• 'self': autorise les ressources de la même origine que la page web.
• https:: autorise toutes les ressources chargées via HTTPS.

Mise en œuvre et configuration

Pour mettre en œuvre le CSP, le serveur doit inclure la tête Content Security Policy dans les réponses HTTP envoyées aux clients.

La configuration du CSP est flexible et peut être ajustée en fonction des besoins spécifiques de la sécurité du site.

La politique doit être précise pour éviter de compromettre l’utilisabilité ou la sécurité.

Les administrateurs de site peuvent tester leur politique avec l’en-tête Content-Security-Policy-Report-Only, qui signale les violations sans bloquer les contenus.

• La tête CSP est ajoutée aux réponses HTTP.
• Utiliser Content-Security-Policy-Report-Only pour tester la politique avant de l’appliquer.

Pour aller plus loin : Déjouer une attaque DNS : Stratégies essentielles de prévention et de réponse

Les en-têtes de réponse CSP

Les en-têtes de réponse CSP (Content Security Policy) sont essentiels pour définir et contrôler les ressources autorisées à être chargées par un navigateur sur une page web, offrant ainsi une couche de sécurité supplémentaire.

Content-Security-Policy Header

L’en-tête de réponse HTTP Content-Security-Policy permet aux administrateurs de sites web de restreindre les ressources externes pouvant être chargées ou exécutées sur leur site.

Cela implique de déterminer explicitement les origines fiables pour les scripts, les images, les feuilles de style, et plus encore.

Par exemple :

• Scripts : script-src 'self' https://apis.example.com;
• Images : img-src 'self' https://images.example.com;

L’utilisation de cet en-tête aide à prévenir un large éventail d’attaques, telles que le cross-site scripting (XSS).

Content-Security-Policy-Report-Only

L’en-tête Content-Security-Policy-Report-Only fonctionne de manière similaire à Content-Security-Policy, mais au lieu de bloquer les ressources non conformes, il sert à enregistrer des rapports.

Les violations de la politique CSP sont signalées à une URL spécifiée par l’administrateur.

Ce mode permet de tester les politiques sans les appliquer, ce qui est utile pour le débogage et le développement. Voici comment on le définit :

• Rapport : Content-Security-Policy-Report-Only: default-src 'self'; report-uri /my_reporting_endpoint;

Un rapport est ainsi généré chaque fois qu’une tentative de chargement d’une ressource viole la politique de sécurité définie, sans bloquer la ressource.

Gestion des ressources

La gestion des ressources dans le cadre du CSP implique la définition de directives spécifiques qui contrôlent la source et le type de contenu pouvant être exécuté ou stylisé sur une page web. Ces règles sont essentielles pour limiter les vecteurs d’attaques potentiels tels que le Cross-Site Scripting (XSS).

Directives pour les scripts

Les directives pour les scripts déterminent quelles sources de scripts sont autorisées.

L’utilisation de 'nonce-' permet d’accepter les scripts possédant un nonce qui correspond à celui spécifié.

La directive 'unsafe-inline', bien que contre-indiquée, permet d’inclure des scripts inline ou dynamiques.

• Example :
  • script-src 'self' https://api.exemple.com;

Directives pour les styles

Les directives pour les styles servent à indiquer quelles sources de feuilles de style sont autorisées.

Similar to the script directives, 'nonce-' can be used to allow inline styles with a matching nonce.

Using 'unsafe-inline' allows for inline style elements and attributes, which is typically avoided for better security.

• Example :
  • style-src 'self' 'nonce-2726c7f26c';

Directives pour les images

Pour les directives pour les images, le CSP détermine les sources d’images considérées comme sûres.

Cela peut inclure des domaines spécifiques ou des protocoles tels que le data URI.

• Example :
  • img-src 'self' data:;

Management des médias et fonts

La directive media-src contrôle les origines autorisées pour le chargement de médias tels que les vidéo et les audio.

La directive font-src, d’autre part, spécifie les serveurs fiables pour le téléchargement de polices de caractère.

• Tableau des directives : Ressource Directive Média media-src 'self' https://media.exemple.com; Police font-src 'self' https://fonts.exemple.com;

Autres ressources à contrôler

Le CSP ne se limite pas aux scripts, styles et images.

La directive default-src est une directive générique s’appliquant à la plupart des catégories de ressources en l’absence d’une directive spécifique.

Les frames peuvent être réglementées à l’aide de frame-src pour éviter le chargement de contenus tiers non sécurisés.

• Example :
  • default-src 'none'; frame-src 'self' https://frame.exemple.com;

Sujet similaire : Injection SQL : les meilleures méthodes pour sécuriser vos bases de données

Renforcement de la sécurité

La Content Security Policy (CSP) est un outil puissant de renforcement de la sécurité qui permet de contrôler et de limiter les risques d’attaques malveillantes sur un site web.

Elle offre des mécanismes spécifiques pour protéger contre certaines des vulnérabilités les plus communes.

Protection contre les attaques Cross-Site Scripting

La CSP aide à prévenir les attaques de type Cross-Site Scripting (XSS) en définissant les sources fiables pour le chargement de code JavaScript.

Elle empêche l’exécution de scripts non autorisés susceptibles d’être injectés par des attaquants et de compromettre la sécurité du site et de ses utilisateurs.

Restreindre les contenus de sources externes

Les directives CSP permettent de restreindre les contenus pouvant être chargés sur une page web.

En spécifiant les sources valides pour les différentes types de contenus, tels que les images, les CSS ou les scripts, l’administrateur impose un contrôle strict sur les ressources externes, limitant ainsi les risques liés à des contenus malveillants.

Utilisation des nonces et des hashs

L’utilisation de nonces (numéros utilisés une seule fois) et de hashs permet de s’assurer que seuls les scripts et les styles spécifiquement approuvés soient exécutés.

À chaque chargement de page, un nonce unique est généré, offrant ainsi une couche supplémentaire de sécurité.

Directives ‘self’ et ‘none’

Les directives 'self' et 'none' jouent un rôle crucial dans la définition de la politique de sécurité.

'self' autorise le chargement de ressources uniquement à partir de la même origine que celle du document, tandis que 'none' bloque tout chargement de ressources de l’origine spécifiée.

Ces directives permettent de créer une liste blanche ou une liste noire efficace pour le chargement de contenu.

À lire sur le même sujet : Rançongiciel : Comprendre et se protéger de ces cyberattaques

Quelques statistiques

En réponse à l’escalade continue des cybercrimes, le secteur de la cybersécurité évolue.

Selon une récente étude, il est prévu que le coût mondial des cybercrimes atteigne près de 9,5 trilliards de dollars en 2024 et dépasse les 10,5 trilliards de dollars en 2025.

Aux États-Unis, une analyse du FBI évoque des pertes potentielles liées aux cyberattaques et aux fraudes qui excéderaient les 10,2 milliards de dollars en 2022.

Bien que le nombre de plaintes reçues par le Centre de plaintes pour crimes sur Internet du FBI ait diminué de 5% en 2022, passant à plus de 800 000 rapports, la valeur totale des pertes a cru de 49%.

L’incident le plus fréquemment signalé était le phishing, suivi par les violations de données personnelles et les défauts de paiement ou de livraison.

En chiffres plus alarmants, les fraudes liées aux investissements ont occasionné des pertes substantielles de 3,3 milliards de dollars, soit une augmentation de 127 % par rapport à 2021.

Ces sombres statistiques dépeignent la gravité du paysage de la cybercriminalité actuel et soulignent l’importance d’adopter des mesures de sécurité robustes telles que les Content Security Policy (CSP) pour protéger les internautes et les entreprises en ligne.

Rapports et violations

La gestion des rapports et violations liées à la Content Security Policy (CSP) est un aspect indispensable pour surveiller et renforcer la sécurité des pages web.

Report-uri et Report-to

La directive report-uri spécifie l’endroit où le navigateur doit envoyer les rapports de violation de la politique CSP.

Lorsque des règles CSP sont violées, le navigateur envoie un rapport JSON à l’URI indiquée, fournissant ainsi aux propriétaires du site web des données précieuses sur les violations rencontrées.

Historiquement, report-uri a été la première implémentation pour la collecte de rapports CSP.

Toutefois, avec l’évolution des standards, la directive report-to a été introduite pour remplacer report-uri.

Elle fonctionne de concert avec l’en-tête Report-To, permettant ainsi une configuration plus flexible et un groupe de rapports qui peut être utilisé par d’autres types de rapports de navigateur, pas seulement CSP.

Analyse des rapports de violation

Une fois que les rapports de violation CSP sont reçus, leur analyse est primordiale pour identifier et corriger les faiblesses de la politique de sécurité en place.

Ces rapports détaillent le type de violation, la ressource affectée et la page web concernée, offrant ainsi un diagnostic précis.

L’utilisation de services ou d’outils d’analyse dédiés peut grandement faciliter la gestion et le traitement de grandes quantités de rapports.

Cela permet également d’ajuster en continu la CSP pour améliorer la sécurité du site web sans altérer son fonctionnement optimal.

Pour aller plus loin : Qu’est-ce qu’un pare-feu applicatif ?

Bonnes pratiques et configuration avancée

Lorsqu’on aborde la Content Security Policy (CSP), la mise en œuvre de bonnes pratiques et une configuration avancée sont essentielles pour maximiser son efficacité.

Une politique CSP bien configurée permet d’établir des contrôles de sécurité robustes et de minimiser les risques d’attaques via des scripts malveillants injectés.

Exemples de politiques CSP

Directive ‘default-src’ : Cette directive définit les sources par défaut pour charger les ressources. Un exemple de politique stricte serait:

Content-Security-Policy : default-src 'self'; 

Cette configuration permet uniquement le chargement des ressources du même domaine que la page chargée, excluant ainsi les sources tierces potentiellement malveillantes.

Directive ‘script-src’ : Pour détailler la politique des scripts, on utilise ‘script-src’. Exemple:

Content-Security-Policy : script-src 'self' https://apis.exemple.com; 

Ici, les scripts sont autorisés à être chargés du domaine d’origine et du service de confiance https ://apis.exemple.com.

Configurer pour le déploiement productif

Test en mode ‘Report-Only’ : Avant le déploiement en production, il convient de tester la CSP en mode ‘Report-Only’.

Utiliser l’en-tête HTTP Content-Security-Policy-Report-Only pour observer les violations sans bloquer les ressources :

Content-Security-Policy-Report-Only : default-src 'self'; report-uri /csp-violations-report-endpoint; 

Utilisation avec des workers : Lors de l’utilisation des workers, il est important d’inclure des directives spécifiques dans la CSP pour garantir qu’ils opèrent dans un environnement contrôlé. Par exemple :

Content-Security-Policy : default-src 'self'; child-src 'none'; worker-src 'self'; 

Cette politique permet le chargement des workers du même domaine et interdit le chargement de workers via iframe (child-src 'none').

Outils de génération et de test du CSP

Des outils de génération de CSP aident les développeurs à créer une politique de sécurité adaptée à leurs besoins spécifiques.

L’un des aspects cruciaux est la facilité avec laquelle ces outils intègrent les directives nécessaires pour prévenir diverses attaques, telles que les attaques par script intersite (XSS).

Les outils de test permettent ensuite de valider l’efficacité de la politique CSP avant son déploiement en production.

• CSP Evaluator : Un outil populaire fourni par Google qui permet d’analyser si une politique CSP est bien configurée.
• CSP Generator : Permet de générer une politique CSP à partir des réglages préconçus ou personnalisés par l’utilisateur.

Extensions navigateur et analyseurs de CSP

L’utilisation d’extensions de navigateur aide à analyser et à déboguer les politiques CSP des pages web pendant que les développeurs naviguent sur leurs sites.

Ces extensions peuvent signaler et aider à résoudre les violations de politique CSP.

Les analyseurs de CSP examinent une politique en place et recommandent des améliorations pour renforcer la sécurité.

• CSP Viewer : Extension de navigateur qui affiche la politique CSP des sites web visités.
• Report URI : Un service en ligne qui propose un analyseur de CSP et une plateforme pour suivre les violations de politique.

Compatibilité et limitations

La mise en œuvre du Content Security Policy (CSP) présente des défis variés, notamment en termes de compatibilité avec les navigateurs et les limites inhérentes à cette technologie en matière de sécurisation des applications web.

Support navigateur et problèmes de compatibilité

La prise en charge du CSP varie d’un navigateur à l’autre, influençant directement la compatibilité et l’intégration du CSP sur les sites web.

Les navigateurs modernes tels que Chrome, Firefox, Safari et Edge offrent un bon niveau de support pour CSP, mais des nuances existent quant aux versions et aux directives spécifiques prises en charge.

Par exemple :

• Chrome/Opera : Support complet depuis la version 25/15.
• Firefox : Support depuis la version 23, mais avec quelques directives non supportées avant la version 45.
• Safari : Partiellement supporté à partir de la version 7, mais certaines directives comme report-uri peuvent ne pas fonctionner comme prévu.
• Edge : Support depuis la version 12 avec des limitations sur certaines directives.

Des problèmes de compatibilité peuvent survenir lors de l’utilisation de directives non supportées, ou lorsque des directives sont appliquées de manière plus stricte dans certains navigateurs.

Ces différences peuvent se traduire par des comportements inattendus et des erreurs dans le chargement des ressources, conduisant parfois à la nécessité d’implémenter des solutions de contournement ou de dégradation progressive.

Limites et problématiques rencontrées

Le CSP vise à renforcer la sécurité des sites en contrôlant les ressources chargées, toutefois, il rencontre certaines limitations.

Il ne peut, par exemple, pas bloquer les attaques de type CSRF (Cross-Site Request Forgery) ou protéger contre un script malveillant déjà installé sur le serveur.

Voici quelques problématiques communes:

• Politiques ambiguës : Des directives trop permissives peuvent peu contribuer à la sécurité, alors qu’une politique trop restrictive peut casser des fonctionnalités du site.
• Maintenance des politiques : La maintenance du CSP peut s’avérer complexe, surtout pour les grands sites dynamiques où les ressources changent fréquemment.
• Problèmes de performance : L’utilisation de directives telles que ‘nonce’ ou ‘hash’ peut entraîner des problèmes de performance pour les sites avec de nombreux éléments inline.
• Rapports : Les mécanismes de rapport de CSP sont utiles, mais peuvent générer un volume important de données à analyser, requérant donc une gestion dédiée.

Sujet similaire : Qu’est-ce que la sécurité DNS ?