# worker-src (/fr/docs/web-security/policies/content-security-policy/directives/worker-src) La directive `worker-src` de la politique de sécurité du contenu (CSP) contrôle les sources qu'une page peut charger comme scripts `Worker`, `SharedWorker` et `ServiceWorker`. Un worker dont l'URL de script n'est pas autorisée est bloqué, et le navigateur envoie un report de violation. Une politique minimale sûre pour cette directive : ```http Content-Security-Policy: worker-src 'self' ``` ## Chaîne de repli [#chaîne-de-repli] `worker-src` a l'une des chaînes de repli les plus longues parmi les directives fetch standard. Quand elle est absente, le navigateur descend vers [`child-src`](/fr/docs/web-security/policies/content-security-policy/directives/child-src), puis [`script-src`](/fr/docs/web-security/policies/content-security-policy/directives/script-src), puis `default-src` : ``` worker-src -> child-src -> script-src -> default-src ``` Les workers étant du script, une politique avec `script-src 'self'` et sans `worker-src` restreint déjà les scripts de worker à la même origine. Ne définissez `worker-src` que si les sources de workers doivent différer du reste de votre politique de script. ## Valeurs [#valeurs] `worker-src` prend une liste de sources avec la grammaire standard des directives fetch : [sources d'hôte](/fr/docs/web-security/policies/content-security-policy/values/csp-host-source), [sources de schéma](/fr/docs/web-security/policies/content-security-policy/values/csp-scheme-source), et les [mots-clés](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords) `'self'` ou `'none'` : | Valeur | Statut | Description | | --------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | `'none'` | ✅ Bon | Bloque tous les workers. | | `'self'` | ✅ Bon | Scripts de worker provenant uniquement de l'origine de la page. | | `https://cdn.example` | ✅ Bon | Scripts de worker depuis un hôte précis que vous contrôlez. | | `https:` | ❌ Risqué | N'importe quel hôte HTTPS peut fournir du code de worker, qui s'exécute. | | `blob:` | ❌ Risqué | Nécessaire pour les workers `URL.createObjectURL`, mais élargit ce qui peut s'exécuter comme script ; à n'ajouter qu'en connaissance de cause. | | `*` | ❌ Risqué | Code de worker depuis n'importe où. Ne correspond jamais à `data:` ni `blob:`. | Les nonces et les hashes ne s'appliquent pas ici ; ils couvrent le script inline, tandis que `worker-src` vérifie le script de worker externe par son URL. Les workers sont souvent construits à partir d'une URL `blob:` (`new Worker(URL.createObjectURL(...))`) : une page qui procède ainsi a besoin de `blob:` dans la directive résolue. Ne l'ajoutez qu'en connaissance de cause, car une autorisation `blob:` large élargit ce qui peut s'exécuter comme script. ## Exemples [#exemples] ```http Content-Security-Policy: worker-src 'self' https://cdn.example.com ``` Cela autorise les scripts de worker chargés depuis l'origine de la page et depuis un hôte précis que vous contrôlez, et bloque tout autre script de worker cross-origin. ## Notes de sécurité [#notes-de-sécurité] Limiter les sources de workers empêche un attaquant de lancer un script en arrière-plan depuis une origine que vous ne contrôlez pas. Un worker s'exécute hors du thread principal, peut émettre des requêtes réseau et héberger un service worker qui intercepte les requêtes ultérieures : contrôler la provenance de son code fait donc partie du confinement de l'injection de script, aux côtés de [`script-src`](/fr/docs/web-security/policies/content-security-policy/directives/script-src). ## Contournements et risques connus [#contournements-et-risques-connus] Une fois installé depuis une source autorisée, un service worker persiste et peut intercepter les requêtes suivantes : un `worker-src` trop large porte donc bien au-delà d'une requête ponctuelle. Si vous vous reposez sur le repli `script-src`, n'oubliez pas qu'élargir `script-src` (en ajoutant un CDN, par exemple) élargit du même coup la provenance possible des workers. ## Recommandation [#recommandation] ```http Content-Security-Policy: worker-src 'self' ``` Un script de worker s'exécute : traitez-le comme `script-src` et gardez-le sur votre propre origine. N'ajoutez `blob:` que si votre application construit des workers avec `URL.createObjectURL`, et évitez les schémas nus et `*`, qui laissent n'importe quel hôte fournir du code de worker exécutable. ## Reporting [#reporting] Quand un script de worker est bloqué, le navigateur envoie un [report csp-violation](/fr/docs/web-security/reporting-api/reports/csp-violation) avec `worker-src` comme `effectiveDirective`, URL bloquée comprise. CentralCSP collecte et agrège ces reports, de quoi voir chaque source de worker que vos pages utilisent réellement avant de resserrer la directive. ## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs] Largement prise en charge par les navigateurs actuels dans le cadre de CSP niveau 3. Là où `worker-src` n'est pas définie, les replis [`child-src`](/fr/docs/web-security/policies/content-security-policy/directives/child-src) et [`script-src`](/fr/docs/web-security/policies/content-security-policy/directives/script-src) s'appliquent. ## Voir aussi [#voir-aussi] * [script-src](/fr/docs/web-security/policies/content-security-policy/directives/script-src), la directive de script plus large sur laquelle worker-src se replie * [child-src](/fr/docs/web-security/policies/content-security-policy/directives/child-src), le repli partagé avec frame-src * [Évaluer une politique](/tools/csp-evaluator) avec l'évaluateur CSP ## Sources [#sources] * [MDN, CSP worker-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/worker-src) * [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)