Content security policy : comment le déployer ?

author

Boris Schapira

10 août 2022 | 4 minutes - Temps de lecture

Last Updated: Jan 3, 2023


Après avoir découvert l’intérêt de CSP pour se prémunir des risques en lien avec l’injection de contenus sur vos pages web, je vous propose des éléments techniques sur l’implémentation de CSP, mais aussi des réflexions sur la méthodologie à adopter.

Avec Error Analysis de Contentsquare, on peut détecter que de nombreuses erreurs provoquent des pertes au regard d’objectifs business. Une CSP bien maîtrisée empêche l’exécution de script client ou issus d’extension susceptible d’altérer le fonctionnement prévu de la page web.

Content security policy ou CSP, qu’est ce c’est ?

CSP est un simple header HTTP, donc pas de grande difficulté technique de ce côté pour la mise en place. Par exemple pour Apache, c’est une simple ligne de configuration :

<IfModule mod_headers.c>

Header set Content-Security-Policy “script-src ‘self’ https://www.domainedeconfiance.com”

</IfModule>

Pour vous y retrouver avec les différentes options, certains générateurs pourront vous apporter une aide précieuse, par exemple celui de Report URI ou encore cspisawesome.com

Mais ne vous lancez pas sans réflexion : la moindre erreur de configuration de CSP pourrait entraîner des dysfonctionnements importants sur votre site !

Heureusement, vous pouvez utiliser le header Content-Security-Policy-Report-Only, équivalent de Content-Security-Policy, mais qui, comme son nom l’indique, se contentera de remonter des informations en cas de violation de la politique (sans  conduire à un blocage donc). Passer par le mode report only est donc un excellent moyen de tester vos configurations.

Vous pouvez tout à fait cumuler Content-Security-Policy et Content-Security-Policy-Report-Only, très utile pour avoir une approche incrémentale pour tendre vers une politique de moins en moins permissive.

Avant de mettre en place CSP, pensez à vos workflows : qui peut ajouter des contenus ? sous quels délais ? avec quelle validation ? qui est chargé de mettre à jour CSP ?

Cela vous permettra d’éviter des écueils importants. Pensez notamment aux systèmes de tags manager, qui offrent généralement une souplesse importante aux équipes marketing, mais dont le fonctionnement nécessitera souvent une mise à jour de votre CSP.

Speed Analysis en vidéo

Plongez dans les pages et les parcours pour obtenir des informations et des alertes approfondies sur les performances Web !

Voir la vidéo

Content Security Policy, les options disponibles les plus connues (directives et valeurs)

default-src la politique par défaut, utilisée partout sauf si surchargée par une directive plus précise
script-src la politique dédiée aux scripts
object-src la politique dédiée aux plugins (éléments object, embed, ou applet)
style-src la politique dédiée aux styles (CSS)
img-src la politique dédiée aux images (element img, mais aussi url() ou image() depuis une CSS, ou encore élément link lié à une image (ex: rel=”icon”)
media-src la politique dédiée aux medias (éléments video, audio, source, ou track)
frame-src la politique dédiée aux frames (éléments iframe ou frame).NB : directive dépréciée par CSP level 2
worker-src la politique dédié aux service worker, définissant les ressources valides pour les traitements en tâche de fond
font-src la politique dédiée aux polices de caractères
connect-src la politique dédiée à l’établissement de connexions depuis un objet XMLHttpRequest ou une WebSocket, très utilisée pour les APIs
report-uri Permet de définir une URI à laquelle sera envoyée les éventuels rapports de violation de votre CSP : si une ressource est bloquée par un navigateur visitant la page, le navigateur enverra un rapport avec des informations détaillées à cette URI.Attention à la gestion des rapports : si votre trafic est important, le volume pourrait être considérable !

Les directives xxx-src peuvent accepter comme valeur : ‘none’, le caractère * (tout autoriser) ou une combinaison de ces valeurs :

  • ‘self’ (le domaine courant)
  • liste de domaines (séparés par une virgule, avec utilisation possible de *.mondomaine.com )
  • data: (par exemple pour autoriser les images en base64)

script-src et style-src acceptent également la valeur ‘unsafe-inline’ pour autoriser l’utilisation de scripts ou de styles inline dans votre HTML.

Attention donc aux effets de bord que vous pourriez rencontrer avec une directive “default-src” qui ne propose pas de valeur ‘unsafe-inline’. L’utilisation d’un “default-src” non complétée d’un style-src ‘unsafe-inline’ conduira donc au blocage des styles inline !

Pour finir, les directives suivantes ont été introduites avec CSP level 2 et 3 : base-uri, child-src, form-action, frame-ancestors, plugin-types, prefetch-src, navigate-to. CSP 3 permet également d’autoriser spécifiquement certains scripts ou styles inline par exemple, en offrant donc davantage de granularité à ce sujet. Pour en savoir plus vous pouvez consulter la spécification, qui nous précise également ce passage que je vous invite à retenir :

In order to protect against Cross-Site Scripting (XSS), web application authors SHOULD include:

  • include a default-src directive, which covers both scripts and plugins.

In either case, authors SHOULD NOT include either ‘unsafe-inline’ or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely.

En résumé : pour se prémunir des attaques XSS vous devez utiliser default-src ou la combinaison  de script-src et object-src, et ne pas autoriser unsafe-inline ou data: dans ces politiques.

Astuce : dans la plupart des situations où “unsafe-inline” est demandé pour “script-src”, vous pouvez le remplacer par un condensé (hash) tel que ‘sha256-abcd…’, qui permettra au navigateur de n’autoriser que les scripts inlines de votre choix.

Speed Analysis en vidéo

Plongez dans les pages et les parcours pour obtenir des informations et des alertes approfondies sur les performances Web !

Voir la vidéo

CSP, un outil puissant, à utiliser prudemment

Pour conclure sur CSP, on retiendra que c’est un outil très puissant, dont les bienfaits ne s’arrêtent pas à la couche de sécurité supplémentaire apportée. Même si sa mise en œuvre sur des sites web d’envergure peut apparaître complexe, CSP propose un mode Report-Only qui permettra d’avoir une approche progressive et solide.

Et quand on sait la fréquence des failles XSS et les problèmes que peuvent poser les contenus de tierces parties, l’effort que cela représente paraît bien moindre.