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 poste vers un domaine étranger. 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. Il s'agit d'observabilité et de gestion de politique par-dessus ce que le navigateur fait déjà, et non d'un proxy ou d'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 livrent la politique 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.

Le cas du XSS est la raison pour laquelle la plupart des équipes adoptent 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 d'abord 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 à cesser d'autoriser des hôtes pour les scripts et à faire plutôt confiance à des scripts individuels.

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 les directives restantes explicitement, y compris les directives de 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 nonce {RANDOM} frais par réponse et placez la même valeur sur chaque <script> de confiance. Ne desserrez une seule directive que lorsque le site en a besoin (un CDN d'images dans img-src, une frame que vous intégrez dans frame-src) ; gardez le reste.

Vous pouvez vérifier un brouillon de politique par rapport à ces règles avec le évaluateur CSP, et scanner un site en production pour ses headers actuels 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 poste vers un domaine étranger. 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 observer ce qui casserait, puis déplacez la même chaîne vers 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