← Tous les articles

CSP pour les services Google, la fiche des hosts

CentralCSP Team ·

Dernière mise à jour:

Les services Google font partie des choses qu'une politique de sécurité du contenu (CSP) casse le plus souvent, car chacun charge depuis son propre ensemble de hosts et déclenche une directive différente. La tentation est d'élargir toute la politique jusqu'à ce que la casse s'arrête, ce qui annule discrètement la protection. Voici plutôt une fiche par service : les directives précises dont chacun a besoin, pour ajouter exactement ce qu'il faut et rien de plus.

Ajoutez-les d'abord en Report-Only, confirmez que rien d'autre ne casse, puis passez en mode enforce. Pour Analytics et Tag Manager en particulier, voyez l'article dédié CSP pour Google Analytics et Tag Manager, qui détaille le nonce dont ils ont besoin.

Les listes de hosts ci-dessous sont un point de départ, pas une vérité gravée dans le marbre. Google change de hosts avec le temps, et votre ensemble exact dépend des fonctionnalités que vous activez. Vérifiez par un scan les hosts que votre site charge vraiment, plutôt que de recopier une liste statique à l'aveugle.

Google Fonts

Google Fonts se charge en deux temps : une feuille de style depuis un host, puis les fichiers de police qu'elle référence depuis un autre. Il vous faut les deux directives, sinon le texte s'affiche avec une police système.

Content-Security-Policy:
    style-src 'self' https://fonts.googleapis.com;
    font-src 'self' https://fonts.gstatic.com

Google Maps

L'API JavaScript de Google Maps est plus lourde : elle charge son JavaScript, récupère les tuiles de carte sous forme d'images, et fait des appels API pour le géocodage et les itinéraires. Cela touche trois directives.

Content-Security-Policy:
    script-src 'self' https://maps.googleapis.com;
    img-src 'self' https://maps.gstatic.com https://*.googleapis.com https://*.ggpht.com data:;
    connect-src 'self' https://maps.googleapis.com

Les wildcards sur img-src couvrent les hosts de tuiles que maps.gstatic.com ne couvre pas à lui seul : les tuiles Street View viennent de geo*.ggpht.com et les tuiles satellite de khms*.googleapis.com, que *.ggpht.com et *.googleapis.com autorisent. Le guide CSP de l'API JavaScript Maps de Google liste exactement cet ensemble.

reCAPTCHA

reCAPTCHA charge un script depuis Google et affiche son défi dans une frame, il a donc besoin à la fois de script-src et de frame-src. Les recommandations CSP de reCAPTCHA limitent ces sources au chemin /recaptcha/ plutôt qu'à tout le host :

Content-Security-Policy:
    script-src 'self' https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/;
    frame-src https://www.google.com/recaptcha/

Si un réseau ou une région bloque www.google.com, Google documente www.recaptcha.net comme host alternatif. Chargez alors la bibliothèque reCAPTCHA depuis www.recaptcha.net et remplacez partout www.google.com/recaptcha/ par www.recaptcha.net/recaptcha/, dans script-src comme dans frame-src, pour que l'origine du script et celle de la frame restent alignées.

Intégrations YouTube

Un lecteur YouTube intégré tourne dans une iframe, et les vignettes de prévisualisation se chargent comme des images, il vous faut donc frame-src pour le lecteur et img-src pour les vignettes. Google ne publie pas de page CSP YouTube canonique unique, donc cette liste est reconstituée à partir des domaines de service documentés par YouTube : la frame du lecteur vient de www.youtube.com ou www.youtube-nocookie.com, et les vignettes de i.ytimg.com.

Content-Security-Policy:
    frame-src https://www.youtube-nocookie.com https://www.youtube.com;
    img-src 'self' https://i.ytimg.com

Autorisez les deux hosts de frame. Le domaine de confidentialité youtube-nocookie.com pose moins de cookies de suivi et utilise la même intégration, mais un lecteur peut encore basculer sur www.youtube.com pour les liens de vidéos associées, et n'autoriser que le host nocookie casse ces liens.

Les scripts de publicité et de tags sont les entrées les plus larges et les plus risquées de cette liste, car Tag Manager existe précisément pour injecter d'autres scripts, et un emplacement publicitaire peut charger du code que vous n'avez jamais relu. Autoriser un à un tous les hosts qu'ils pourraient atteindre transforme la politique en passoire. C'est exactement le cas pour lequel 'strict-dynamic' est fait : faire confiance au conteneur par nonce et le laisser se porter garant de ce qu'il charge, au lieu de maintenir une liste de hosts qui ne cesse de grandir. Voyez strict-dynamic expliqué et le guide GA et Tag Manager. Les tags de publicité et de conversion (Google Ads, DoubleClick, Floodlight) atteignent chacun leurs propres hosts, et l'ensemble dépend des tags qui se déclenchent, alors mesurez en Report-Only plutôt que d'autoriser d'avance une liste statique de hosts publicitaires.

Trouvez les hosts que votre site charge vraiment

Pour construire ces listes de façon fiable, arrêtez de deviner et mesurez. Scannez une page en production et laissez les reports de violation vous dire quels hosts sont chargés et lesquels votre politique bloquerait, y compris les tiers que vos tiers font venir (ceux qu'aucune fiche ne peut prédire). Le scanner CSP et le reporting de violations de CentralCSP transforment une vraie page en liste de hosts exacte et à jour.

Étapes suivantes

Scannez votre site et voyez ce que votre CSP bloque.

Sources