# Source hôte (/fr/docs/web-security/policies/content-security-policy/values/csp-host-source) Une source d'hôte est le type de valeur le plus courant d'une politique de sécurité du contenu (CSP) : un motif d'URL qui autorise des ressources provenant d'une origine particulière, comme `https://cdn.example.com` ou `*.example.com`. C'est ainsi que vous mettez en allowlist les tiers depuis lesquels une page peut charger du script, des images, des polices ou des connexions. Les règles de correspondance paraissent simples mais comportent des cas limites qui décident si une vraie requête est autorisée, d'où l'importance des détails ci-dessous. Une source d'hôte telle que vous la déploieriez, un CDN autorisé à côté de votre propre origine : ```http Content-Security-Policy: img-src 'self' https://cdn.example.com ``` ## Syntaxe [#syntaxe] Une source d'hôte est construite à partir de quatre parties, pour la plupart optionnelles : un schéma, un hôte, un port et un chemin. ```http Content-Security-Policy: script-src https://cdn.example.com:443/assets/ ``` La grammaire, lue de gauche à droite : | Partie | Exemple | Signification | | ------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------- | | Schéma | `https://` | Optionnel. S'il est omis, le schéma de la page est supposé, et une source `http:` correspond aussi à `https:`. | | Hôte | `cdn.example.com` | Obligatoire. Un hôte complet, ou un wildcard `*.` en tête pour un niveau de sous-domaine. | | Hôte wildcard | `*.example.com` | Correspond à un seul préfixe de sous-domaine, quel qu'il soit. | | Port | `:443` ou `:*` | Optionnel. Un port précis, ou `:*` pour n'importe quel port. S'il est omis, le port par défaut du schéma est utilisé. | | Chemin | `/assets/` | Optionnel. Restreint à un chemin ; un `/` final en fait une correspondance par préfixe. | Les motifs que vous écrivez réellement se réduisent à quelques formes, et elles ne sont pas toutes aussi sûres. | Motif | Statut | Description | | ------------------------- | -------- | ---------------------------------------------------------------------------------------------------- | | `https://cdn.example.com` | ✅ Bon | Un hôte précis en HTTPS, la forme la plus étroite d'allowlisting. | | `*.example.com` | ✅ Bon | N'importe quel sous-domaine de `example.com`, mais pas l'apex `example.com` lui-même. | | `*` | ❌ Risqué | N'importe quel hôte sur un schéma réseau. Dans `script-src`, il retire l'essentiel de la protection. | ## Ce à quoi elle correspond [#ce-à-quoi-elle-correspond] Une source d'hôte correspond à une URL de requête lorsque le schéma, l'hôte, le port et le chemin concordent tous selon ces règles. La chaîne de requête et le fragment ne font jamais partie de la correspondance, donc un `?v=2` ou un `#section` sur une URL est ignoré. ```http Content-Security-Policy: img-src https://images.example.com ``` Cela autorise `https://images.example.com/logo.png?cache=off` et tout autre chemin sur cet hôte exact, parce que la query est ignorée et qu'aucun chemin n'a été spécifié. ## Pièges de correspondance [#pièges-de-correspondance] Ces quatre comportements causent la plupart des surprises avec les sources d'hôte. `*.example.com` ne correspond pas à `example.com`. Le wildcard représente une étiquette de sous-domaine, donc `*.example.com` autorise `cdn.example.com` et `static.example.com` mais pas l'apex nu `example.com`. Listez les deux si vous avez aussi besoin de l'apex. ```http Content-Security-Policy: script-src *.example.com example.com ``` Un `*` nu ne correspond pas à `data:`, `blob:` ni `filesystem:`. Le wildcard `*` couvre les schémas réseau (`http:` et `https:`) et n'importe quel hôte, mais le navigateur exclut délibérément les schémas `data:`, `blob:` et `filesystem:`. Si une directive en a besoin, nommez la [source de schéma](/fr/docs/web-security/policies/content-security-policy/values/csp-scheme-source) explicitement, par exemple `img-src * data:`. Un `/` final fait du chemin une correspondance par préfixe. Un chemin se terminant par `/` correspond à ce chemin et à tout ce qui se trouve dessous. Un chemin sans slash final doit correspondre exactement. ```http Content-Security-Policy: script-src https://cdn.example.com/lib/ ``` Cela autorise `/lib/app.js` et `/lib/vendor/chart.js`, mais `/lib` seul (sans slash) n'autoriserait que cette URL exacte. La query et le fragment sont ignorés. Deux URL qui ne diffèrent que par `?query` ou `#fragment` correspondent à la même source d'hôte, donc vous ne pouvez pas autoriser ou bloquer une ressource selon sa chaîne de requête. ## Valeurs non sûres à éviter [#valeurs-non-sûres-à-éviter] Une source d'hôte trop large affaiblit la politique. Un `*` nu dans `script-src` autorise du script depuis n'importe quelle origine, ce qui retire l'essentiel de la protection de CSP ; utilisez plutôt un nonce ou un hash. Un wildcard comme `*.googleapis.com` ou `https:` dans `script-src` fait confiance à chaque hôte sous ce schéma ou ce domaine, y compris ceux qu'un attaquant pourrait contrôler ou détourner via une redirection ouverte. Préférez le [schéma strict-dynamic](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords) plutôt que de maintenir une allowlist d'hôtes de script. ## Contre quoi cela protège [#contre-quoi-cela-protège] Les sources d'hôte permettent à une politique de dire exactement quelles origines peuvent servir chaque type de ressource, ce qui bloque un `