# child-src (/fr/docs/web-security/policies/content-security-policy/directives/child-src) La directive `child-src` contrôle les sources des contextes de navigation imbriqués et des workers sous une politique de sécurité du contenu (CSP). Dans CSP niveau 3, c'est un repli historique : elle se situe entre les directives spécifiques ([`frame-src`](/fr/docs/web-security/policies/content-security-policy/directives/frame-src) pour les frames, [`worker-src`](/fr/docs/web-security/policies/content-security-policy/directives/worker-src) pour les workers) et [`default-src`](/fr/docs/web-security/policies/content-security-policy/directives/default-src). Préférez les directives spécifiques. `child-src` est historique, donc le bon usage est la forme moderne, définissez plutôt les deux directives spécifiques : ```http Content-Security-Policy: frame-src https://embed.example.com; worker-src 'self' ``` ## Chaîne de repli [#chaîne-de-repli] `child-src` retombe elle-même sur [`default-src`](/fr/docs/web-security/policies/content-security-policy/directives/default-src), et elle sert de cible de repli pour deux autres directives : * [`frame-src`](/fr/docs/web-security/policies/content-security-policy/directives/frame-src) retombe sur `child-src`, puis sur `default-src`. * [`worker-src`](/fr/docs/web-security/policies/content-security-policy/directives/worker-src) retombe sur `child-src`, puis sur [`script-src`](/fr/docs/web-security/policies/content-security-policy/directives/script-src), puis sur `default-src`. Donc si vous définissez `child-src` mais ni `frame-src` ni `worker-src`, les frames et les workers utilisent tous deux la valeur de `child-src`. Si vous définissez `frame-src` ou `worker-src` directement, elles prennent le relais et `child-src` ne s'applique plus à elles. ## Valeurs [#valeurs] `child-src` prend une liste de sources séparées par des espaces, combinant [sources mot-clé](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords), [sources d'hôte](/fr/docs/web-security/policies/content-security-policy/values/csp-host-source) et [sources de schéma](/fr/docs/web-security/policies/content-security-policy/values/csp-scheme-source) : | Valeur | Statut | Description | | ------------------- | -------- | ----------------------------------------------------------------------------------- | | `'none'` | ✅ Bon | Bloque toutes les frames et tous les workers. | | `'self'` | ✅ Bon | Frames et workers provenant uniquement de l'origine de la page. | | `embed.example.com` | ✅ Bon | Un hôte précis, appliqué à la fois aux frames et aux workers. | | `https:` | ❌ Risqué | N'importe quel hôte HTTPS peut fournir du code de worker via le repli. | | `blob:` | ❌ Risqué | S'applique aux workers via le repli et élargit ce qui peut s'exécuter comme script. | | `*` | ❌ Risqué | Frames et workers depuis n'importe où. Ne correspond jamais à `data:` ni `blob:`. | Les nonces et les hashes ne s'appliquent pas. ## Exemples [#exemples] ```http Content-Security-Policy: default-src 'self'; frame-src https://embed.example.com; worker-src 'self' ``` Cette politique définit les frames et les workers directement et n'utilise pas du tout `child-src`, ce qui est la forme recommandée. Vous ne recourriez à `child-src` que pour couvrir les deux à la fois dans une politique qui ne nomme pas les directives spécifiques. ## Usage courant [#usage-courant] Dans CSP niveau 2, `child-src` était la directive unique pour les iframes et les workers. CSP niveau 3 a scindé cette responsabilité : les frames sont passées à [`frame-src`](/fr/docs/web-security/policies/content-security-policy/directives/frame-src) et les workers à [`worker-src`](/fr/docs/web-security/policies/content-security-policy/directives/worker-src), ce qui permet de définir des règles différentes pour chacun. `child-src` fonctionne toujours comme repli pour la compatibilité, mais les nouvelles politiques devraient définir les deux directives spécifiques, car regrouper frames et workers sous une seule règle est rarement ce que vous voulez. ## Notes de sécurité [#notes-de-sécurité] Parce que `child-src` couvre à la fois les frames et les workers, l'utiliser comme unique contrôle signifie qu'une seule liste de sources régit deux capacités très différentes : quels sites vous intégrez, et d'où viennent vos scripts de worker. Les scripts de worker s'exécutent, donc ils méritent une règle plus stricte que celle dont les frames intégrées ont généralement besoin. Les séparer avec [`worker-src`](/fr/docs/web-security/policies/content-security-policy/directives/worker-src) et [`frame-src`](/fr/docs/web-security/policies/content-security-policy/directives/frame-src) vous permet de garder les workers à `'self'` tout en intégrant les frames tierces dont vous avez besoin. L'[évaluateur CSP](/tools/csp-evaluator) signale les endroits où une politique repose sur le repli historique. ## Contournements et risques connus [#contournements-et-risques-connus] Le risque n'est pas tant un contournement qu'une distinction manquée. Si vous ne définissez que `child-src`, une valeur permissive choisie pour l'intégration (autoriser la frame d'un widget tiers) s'applique aussi aux sources de scripts de worker, ce qui peut être plus permissif que prévu pour du code exécutable. Définissez les directives spécifiques pour que chacune reçoive la règle qui lui convient. ## Recommandation [#recommandation] ```http Content-Security-Policy: frame-src https://embed.example.com; worker-src 'self' ``` Ne construisez pas une nouvelle politique sur `child-src` ; c'est le parapluie historique de CSP niveau 2. Définissez [`frame-src`](/fr/docs/web-security/policies/content-security-policy/directives/frame-src) et [`worker-src`](/fr/docs/web-security/policies/content-security-policy/directives/worker-src) directement pour que les frames intégrées et le code de worker exécutable aient chacun leur propre règle. ## Reporting [#reporting] Quand le chargement d'une frame ou d'un worker est bloqué, le navigateur envoie un [report csp-violation](/fr/docs/web-security/reporting-api/reports/csp-violation) ; le champ `effectiveDirective` nomme la directive qui a régi le chargement (`frame-src` ou `worker-src`, résolue via la chaîne de repli). CentralCSP collecte et agrège ces reports, donc vous pouvez voir quels chargements dépendent encore du repli `child-src` avant de scinder la politique. ## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs] `child-src` est prise en charge par tous les navigateurs qui implémentent CSP. La scission en [`frame-src`](/fr/docs/web-security/policies/content-security-policy/directives/frame-src) et [`worker-src`](/fr/docs/web-security/policies/content-security-policy/directives/worker-src) est également largement prise en charge, donc préférez celles-ci. ## Voir aussi [#voir-aussi] * [Directives Content Security Policy](/fr/docs/web-security/policies/content-security-policy/introduction/csp-directives) * [frame-src](/fr/docs/web-security/policies/content-security-policy/directives/frame-src) * [worker-src](/fr/docs/web-security/policies/content-security-policy/directives/worker-src) * [default-src](/fr/docs/web-security/policies/content-security-policy/directives/default-src) * [Suite CSP de CentralCSP](/platform/csp-builder) ## Sources [#sources] * [MDN, CSP child-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/child-src) * [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/) * [W3C CSP editor's draft](https://w3c.github.io/webappsec-csp/)