# 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 ``` Parce que les workers sont du script, une politique avec `script-src 'self'` et sans `worker-src` restreint déjà les scripts de worker à la même origine. Définissez `worker-src` quand 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 ; ajoutez-le délibérément. | | `*` | ❌ 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(...))`), donc une page qui construit ses workers ainsi a besoin de `blob:` dans la directive résolue. Ajoutez-le délibérément, 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. Les workers s'exécutent séparément du thread principal, peuvent faire des requêtes réseau et héberger un service worker qui intercepte les requêtes ultérieures, donc contrôler la provenance de leur code fait 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] Un service worker, une fois installé depuis une source autorisée, persiste et peut intercepter les requêtes futures, donc un `worker-src` trop large a une portée plus longue qu'une requête ponctuelle. Si vous vous reposez sur le repli `script-src`, rappelez-vous qu'assouplir `script-src` (par exemple ajouter un CDN) assouplit aussi la provenance possible des workers. ## Recommandation [#recommandation] ```http Content-Security-Policy: worker-src 'self' ``` Les scripts de worker s'exécutent, donc traitez-les comme `script-src` : gardez-les sur votre propre origine. Ajoutez `blob:` seulement 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`, incluant l'URL bloquée. CentralCSP collecte et agrège ces reports, donc vous pouvez 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 retombe * [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/)