# worker-src (/en/docs/web-security/policies/content-security-policy/directives/worker-src)



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:

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

## Fallback chain [#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`](/en/docs/web-security/policies/content-security-policy/directives/child-src),
then [`script-src`](/en/docs/web-security/policies/content-security-policy/directives/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 [#values]

`worker-src` takes a source list using the standard fetch-directive grammar:
[host sources](/en/docs/web-security/policies/content-security-policy/values/csp-host-source),
[scheme sources](/en/docs/web-security/policies/content-security-policy/values/csp-scheme-source),
and the `'self'` or `'none'` [keywords](/en/docs/web-security/policies/content-security-policy/values/csp-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 [#examples]

```http
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 [#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`](/en/docs/web-security/policies/content-security-policy/directives/script-src).

## Known bypasses and risks [#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 [#recommendation]

```http
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 [#reporting]

When a worker script is blocked, the browser sends a [csp-violation report](/en/docs/web-security/reporting-api/reports/csp-violation)
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 [#browser-support]

Widely supported across current browsers as part of CSP Level 3. Where
`worker-src` is not set, the
[`child-src`](/en/docs/web-security/policies/content-security-policy/directives/child-src)
and [`script-src`](/en/docs/web-security/policies/content-security-policy/directives/script-src)
fallbacks apply.

## See also [#see-also]

* [script-src](/en/docs/web-security/policies/content-security-policy/directives/script-src), the broader script directive worker-src falls back to
* [child-src](/en/docs/web-security/policies/content-security-policy/directives/child-src), the fallback shared with frame-src
* [Evaluate a policy](/tools/csp-evaluator) with the CSP evaluator

## 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/)