Ce que c'est

Une politique de sécurité du contenu (CSP) est une liste d'autorisation que vous envoyez sous forme de header de réponse HTTP pour indiquer au navigateur quelles ressources une page peut charger et exécuter. Le navigateur lit la politique et refuse tout ce qui en sort : un script provenant d'un hôte non approuvé, un <script> inline injecté par un attaquant, un formulaire qui envoie ses données vers un domaine tiers. Vous déclarez les règles ; le navigateur les applique côté client.

CentralCSP n'applique pas la politique. C'est le navigateur qui l'applique. CentralCSP collecte les rapports de violation que le navigateur envoie, en construit un inventaire de scripts, et transforme ce flux en monitoring, alerting et preuves. C'est de l'observabilité et de la gestion de politique par-dessus ce que le navigateur fait déjà, pas un proxy ni un pare-feu applicatif web.

À quoi ressemble une politique

Une politique est une chaîne de directives séparées par des points-virgules. Chaque directive est un nom suivi d'une liste de sources ou de mots-clés, séparés par des espaces, que la directive autorise. Les noms de directives ne sont pas sensibles à la casse, et seule la première occurrence d'une directive donnée dans une politique est utilisée.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-r4nd0m';
  object-src 'none';
  base-uri 'none'

Cette politique dit que les scripts peuvent provenir de la même origine ou porter le nonce r4nd0m, que les plugins sont bloqués, que la balise <base> est verrouillée, et que tout le reste se rabat sur la même origine. Chaque élément est détaillé sur sa propre page : les directives qui nomment ce qu'il faut contrôler, les valeurs que chaque directive accepte, et les headers qui transportent la politique jusqu'au navigateur.

Ce contre quoi elle protège

La CSP est un contrôle de défense en profondeur. Elle ne corrige pas le bug qui permet à un attaquant d'injecter du contenu ; elle limite ce que cette injection peut faire une fois en place.

C'est le XSS qui pousse la plupart des équipes à adopter une politique. Si un attaquant injecte une balise <script> dans une page, une politique bien construite empêche ce script de s'exécuter, parce qu'il n'a pas de nonce, pas de hash correspondant, et pas d'hôte autorisé. L'injection a quand même lieu ; le payload ne s'exécute jamais.

La CSP ne remplace pas l'encodage

Une politique réduit l'impact d'une injection, elle n'empêche pas l'injection. Vous avez toujours besoin d'un encodage de sortie contextuel, d'une validation des entrées, et des autres contrôles côté serveur qui empêchent en amont les données non fiables d'arriver dans la page. Traitez la politique comme la seconde couche qui contient une erreur de la première.

La recommandation de la CSP stricte

Les listes d'autorisation d'hôtes sont difficiles à bien régler. Elles ont tendance à s'allonger, elles autorisent souvent des domaines qui hébergent eux-mêmes du contenu contrôlable par un attaquant, et une seule entrée permissive peut mettre en échec toute la politique. La recommandation actuelle, exposée dans le guide web.dev sur la CSP stricte, consiste à ne plus autoriser des hôtes pour les scripts, mais à faire confiance à des scripts précis.

Une politique stricte repose sur quatre éléments :

• Un nonce ou un hash sur script-src pour que seuls les scripts que vous avez marqués puissent s'exécuter.
• strict-dynamic, pour qu'un script de confiance puisse charger les scripts dont il a besoin sans que vous listiez chaque hôte. En sa présence, les entrées d'hôte et de scheme sont ignorées.
• object-src 'none' pour supprimer l'exécution de scripts via les plugins.
• base-uri 'none' pour bloquer l'injection de balise <base>, qui peut sinon rediriger toutes les URL de scripts relatives de la page.

Une politique de base complète définit ces éléments, puis explicitement toutes les autres directives, y compris les directives fetch qui se rabattraient sinon sur default-src, pour que rien ne reste implicite et que le navigateur signale les violations à votre endpoint :

Content-Security-Policy:
    default-src 'self';
    script-src 'nonce-{RANDOM}' 'strict-dynamic';
    style-src 'self';
    img-src 'self';
    font-src 'self';
    connect-src 'self';
    media-src 'self';
    manifest-src 'self';
    frame-src 'none';
    worker-src 'self';
    object-src 'none';
    base-uri 'none';
    form-action 'self';
    frame-ancestors 'none';
    upgrade-insecure-requests;
    report-to csp-endpoint

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Générez un nouveau nonce {RANDOM} à chaque réponse et placez la même valeur sur chaque <script> de confiance. N'assouplissez une directive que lorsque le site l'exige (un CDN d'images dans img-src, une frame que vous intégrez dans frame-src) ; gardez le reste.

Vous pouvez confronter un brouillon de politique à ces règles avec l'évaluateur CSP, et relever les headers actuels d'un site en production avec le scanner CSP. Pour une construction pas à pas, le blog détaille la démarche dans débuter avec CSP et construire une CSP solide.

Comment CentralCSP s'intègre

Une politique stricte se déploie le plus facilement par étapes, en commençant en mode report-only pour observer ce qui casserait avant d'appliquer quoi que ce soit. Le navigateur envoie un rapport de violation CSP pour chaque blocage, et CentralCSP collecte ce flux, le déduplique et fait remonter ce qu'il faut corriger. Les mêmes rapports alimentent un inventaire de scripts, pour que vous puissiez voir chaque script qui tourne sur une page et déployer la politique sans avancer à l'aveugle. Consultez la suite CSP pour l'ensemble des fonctionnalités.

FAQ

Qu'est-ce qu'une politique de sécurité du contenu ?

Une politique de sécurité du contenu est une liste d'autorisation que vous envoyez en header de réponse HTTP pour indiquer au navigateur quelles ressources une page peut charger et exécuter. Le navigateur lit la politique et refuse tout ce qui en sort : un hôte de script non approuvé, un script inline injecté, un formulaire qui envoie ses données vers un domaine tiers. Vous déclarez les règles ; le navigateur les applique.

La CSP arrête-t-elle tous les XSS ?

Non. La CSP est le contrôle le plus fort dans le navigateur contre le XSS, mais elle limite ce qu'une injection peut faire plutôt que d'empêcher l'injection elle-même. Une politique solide empêche un script injecté de s'exécuter parce qu'il n'a ni nonce, ni hash, ni hôte autorisé, mais vous avez toujours besoin d'un encodage de sortie contextuel et de Trusted Types pour tenir les données non fiables hors de la page.

La CSP est-elle difficile à mettre en place ?

Pas si vous la déployez par étapes. Les listes d'autorisation d'hôtes sont difficiles à bien régler, la recommandation actuelle est donc une politique stricte fondée sur un nonce ou un hash plus strict-dynamic. Déployez-la d'abord en mode report-only pour voir ce qui casserait, puis basculez la même chaîne dans le header d'application. Le guide de la CSP solide détaille la construction.

Voir aussi

• Directives CSP
• Valeurs CSP
• Headers CSP
• Content-Security-Policy-Report-Only
• Rapport de violation CSP

Sources

• MDN, Content-Security-Policy
• W3C, Content Security Policy Level 3
• web.dev, Mitigate cross-site scripting with a strict CSP