worker-src directive, control worker script sources in CSP

The CSP worker-src directive controls which sources may be loaded as Worker, SharedWorker, and ServiceWorker scripts. Values and examples.

The worker-src Content Security Policy (CSP) directive controls which sources a page may load as Worker, SharedWorker, and ServiceWorker scripts. A worker whose script URL is not allowed is blocked, and the browser sends a violation report.

A minimal safe policy for this directive:

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

Fallback chain

worker-src has one of the longest fallback chains among the standard fetch directives. When it is absent the browser walks down through child-src, then script-src, then default-src:

worker-src -> child-src -> script-src -> default-src

Because workers are script, a policy with script-src 'self' and no worker-src already restricts worker scripts to the same origin. Set worker-src when worker sources should differ from the rest of your script policy.

Values

worker-src takes a source list using the standard fetch-directive grammar: host sources, scheme sources, and the 'self' or 'none' keywords:

Value	Status	Description
`'none'`	✅ Good	Blocks all workers.
`'self'`	✅ Good	Worker scripts from the page's own origin only.
`https://cdn.example`	✅ Good	Worker scripts from a specific host you control.
`https:`	❌ Risky	Any HTTPS host can supply worker code, which executes.
`blob:`	❌ Risky	Needed for `URL.createObjectURL` workers, but widens what can run as script; add deliberately.
`*`	❌ Risky	Worker code from anywhere. Never matches `data:` or `blob:`.

Nonces and hashes do not apply here; they cover inline script, while worker-src matches the external worker script by its URL.

Workers are often constructed from a blob: URL (new Worker(URL.createObjectURL(...))), so a page that builds workers that way needs blob: in the resolved directive. Add it deliberately, a broad blob: allowance widens what can run as script.

Examples

Content-Security-Policy: worker-src 'self' https://cdn.example.com

This allows worker scripts loaded from the page's own origin and from one specific host you control, and blocks any other cross-origin worker script.

Security notes

Limiting worker sources stops an attacker from spinning up a background script from an origin you do not control. Workers run separately from the main thread and can make network requests and host a service worker that intercepts later requests, so controlling where their code loads from is part of containing script injection alongside script-src.

Known bypasses and risks

A service worker, once installed from an allowed source, persists and can intercept future requests, so an over-broad worker-src has a longer reach than a one-off fetch. If you rely on the script-src fallback, remember that loosening script-src (for example adding a CDN) also loosens where workers may load from.

Recommendation

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

Worker scripts execute, so treat them like script-src: keep them at your own origin. Add blob: only if your app constructs workers with URL.createObjectURL, and avoid bare schemes and *, which let any host supply executable worker code.

Reporting

When a worker script is blocked, the browser sends a csp-violation report with worker-src as the effectiveDirective, including the blocked URL. CentralCSP collects and aggregates these reports, so you can see every worker source your pages actually use before you tighten the directive.

Browser support

Widely supported across current browsers as part of CSP Level 3. Where worker-src is not set, the child-src and script-src fallbacks apply.

worker-src