# CSP pour les services Google, la fiche des hosts (/fr/blog/csp-for-google-services)



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](/fr/blog/csp-enforce-vs-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](/fr/blog/csp-google-analytics-tag-manager),
qui détaille le nonce dont ils ont besoin.

<Callout type="info">
  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.
</Callout>

## Google Fonts [#google-fonts]

[Google Fonts](https://developers.google.com/fonts/docs/getting_started) 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.

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

## Google Maps [#google-maps]

L'[API JavaScript de Google Maps](https://developers.google.com/maps/documentation/javascript)
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.

```http
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](https://developers.google.com/maps/documentation/javascript/content-security-policy)
de Google liste exactement cet ensemble.

## reCAPTCHA [#recaptcha]

[reCAPTCHA](https://developers.google.com/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](https://developers.google.com/recaptcha/docs/faq)
limitent ces sources au chemin `/recaptcha/` plutôt qu'à tout le host :

```http
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 [#intégrations-youtube]

Un lecteur [YouTube](https://developers.google.com/youtube/player_parameters) 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`.

```http
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.

## Google Ads et Tag Manager [#google-ads-et-tag-manager]

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](https://developers.google.com/tag-platform/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é](/fr/blog/strict-dynamic-csp) et le
[guide GA et Tag Manager](/fr/blog/csp-google-analytics-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 [#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](/tools/csp-scanner) et le
[reporting de violations](/fr/docs/platform/monitoring/csp) de CentralCSP transforment une
vraie page en liste de hosts exacte et à jour.

## Étapes suivantes [#étapes-suivantes]

* Construisez la politique de base : [comment construire une CSP solide](/fr/blog/how-to-build-a-strong-csp).
* Abandonnez les allowlists plus tard : [strict-dynamic expliqué](/fr/blog/strict-dynamic-csp).
* Vérifiez le header en production : [scanner de security headers](/tools/security-headers).

[Scannez votre site et voyez ce que votre CSP bloque](/register).

## Sources [#sources]

* [Google, API JavaScript Maps et Content Security Policy](https://developers.google.com/maps/documentation/javascript/content-security-policy)
* [Google, FAQ reCAPTCHA (recommandations CSP et host alternatif recaptcha.net)](https://developers.google.com/recaptcha/docs/faq)
* [Google, utiliser Tag Manager avec une Content Security Policy](https://developers.google.com/tag-platform/security/guides/csp)
* [Google Fonts, démarrage](https://developers.google.com/fonts/docs/getting_started)
