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 :

Content-Security-Policy: worker-src 'self'

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, puis 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

worker-src prend une liste de sources avec la grammaire standard des directives fetch : sources d'hôte, sources de schéma, et les mots-clés 'self' ou 'none' :

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

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é

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.

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

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

Quand un script de worker est bloqué, le navigateur envoie un report 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

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 et script-src s'appliquent.

Voir aussi

• script-src, la directive de script plus large sur laquelle worker-src retombe
• child-src, le repli partagé avec frame-src
• Évaluer une politique avec l'évaluateur CSP

Sources

• MDN, CSP worker-src
• W3C, Content Security Policy Level 3