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

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

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(...))) : 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

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. 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.

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

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

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

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 se replie
• 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