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



The `child-src` directive controls the sources for nested browsing contexts and workers under a Content Security Policy (CSP). In CSP Level 3 it is a legacy fallback: it sits between the specific directives ([`frame-src`](/en/docs/web-security/policies/content-security-policy/directives/frame-src) for frames, [`worker-src`](/en/docs/web-security/policies/content-security-policy/directives/worker-src) for workers) and [`default-src`](/en/docs/web-security/policies/content-security-policy/directives/default-src). Prefer the specific directives.

`child-src` is legacy, so the good use of it is the modern form, set the two specific directives instead:

```http
Content-Security-Policy: frame-src https://embed.example.com; worker-src 'self'
```

## Fallback chain [#fallback-chain]

`child-src` itself falls back to [`default-src`](/en/docs/web-security/policies/content-security-policy/directives/default-src), and it acts as the fallback target for two other directives:

* [`frame-src`](/en/docs/web-security/policies/content-security-policy/directives/frame-src) falls back to `child-src`, then to `default-src`.
* [`worker-src`](/en/docs/web-security/policies/content-security-policy/directives/worker-src) falls back to `child-src`, then to [`script-src`](/en/docs/web-security/policies/content-security-policy/directives/script-src), then to `default-src`.

So if you set `child-src` but not `frame-src` or `worker-src`, both frames and workers use the `child-src` value. If you set `frame-src` or `worker-src` directly, those take over and `child-src` no longer applies to them.

## Values [#values]

`child-src` takes a space-separated source list combining [keyword sources](/en/docs/web-security/policies/content-security-policy/values/csp-keywords), [host sources](/en/docs/web-security/policies/content-security-policy/values/csp-host-source), and [scheme sources](/en/docs/web-security/policies/content-security-policy/values/csp-scheme-source):

| Value               | Status  | Description                                                              |
| ------------------- | ------- | ------------------------------------------------------------------------ |
| `'none'`            | ✅ Good  | Blocks all frames and workers.                                           |
| `'self'`            | ✅ Good  | Frames and workers from the page's own origin only.                      |
| `embed.example.com` | ✅ Good  | A specific host, applied to both frames and workers.                     |
| `https:`            | ❌ Risky | Any HTTPS host can supply worker code through the fallback.              |
| `blob:`             | ❌ Risky | Flows to workers through the fallback and widens what can run as script. |
| `*`                 | ❌ Risky | Frames and workers from anywhere. Never matches `data:` or `blob:`.      |

Nonces and hashes do not apply.

## Examples [#examples]

```http
Content-Security-Policy:
  default-src 'self';
  frame-src https://embed.example.com;
  worker-src 'self'
```

This sets frames and workers directly and does not use `child-src` at all, which is the recommended shape. You would only reach for `child-src` to cover both at once in a policy that does not name the specific directives.

## Common use [#common-use]

In CSP Level 2, `child-src` was the single directive for both iframes and workers. CSP Level 3 split that responsibility: frames moved to [`frame-src`](/en/docs/web-security/policies/content-security-policy/directives/frame-src) and workers to [`worker-src`](/en/docs/web-security/policies/content-security-policy/directives/worker-src), which let you set different rules for each. `child-src` still works as a fallback for compatibility, but new policies should set the two specific directives instead, since lumping frames and workers under one rule is rarely what you want.

## Security notes [#security-notes]

Because `child-src` covers both frames and workers, using it as your only control means a single source list governs two very different capabilities: which sites you embed, and where your worker scripts come from. Worker scripts execute, so they deserve a tighter rule than embedded frames usually need. Splitting them with [`worker-src`](/en/docs/web-security/policies/content-security-policy/directives/worker-src) and [`frame-src`](/en/docs/web-security/policies/content-security-policy/directives/frame-src) lets you keep workers at `'self'` while still embedding the third-party frames you need. The [CSP evaluator](/tools/csp-evaluator) flags where a policy relies on the legacy fallback.

## Known bypasses and risks [#known-bypasses-and-risks]

The risk is not a bypass so much as a missed distinction. If you set only `child-src`, a permissive value you chose for embedding (to allow a third-party widget frame) also applies to worker script sources, which can be more permissive than you intend for executable code. Set the specific directives so each gets the rule it needs.

## Recommendation [#recommendation]

```http
Content-Security-Policy: frame-src https://embed.example.com; worker-src 'self'
```

Do not build a new policy on `child-src`; it is the legacy umbrella from CSP Level 2. Set [`frame-src`](/en/docs/web-security/policies/content-security-policy/directives/frame-src) and [`worker-src`](/en/docs/web-security/policies/content-security-policy/directives/worker-src) directly so embedded frames and executable worker code each get their own rule.

## Reporting [#reporting]

When a frame or worker load is blocked, the browser sends a [csp-violation report](/en/docs/web-security/reporting-api/reports/csp-violation); the `effectiveDirective` names the directive that governed the load (`frame-src` or `worker-src`, resolved through the fallback chain). CentralCSP collects and aggregates these reports, so you can see which loads still depend on the `child-src` fallback before you split the policy.

## Browser support [#browser-support]

`child-src` is supported in every browser that implements CSP. The split into [`frame-src`](/en/docs/web-security/policies/content-security-policy/directives/frame-src) and [`worker-src`](/en/docs/web-security/policies/content-security-policy/directives/worker-src) is also widely supported, so prefer those.

## See also [#see-also]

* [Content Security Policy directives](/en/docs/web-security/policies/content-security-policy/introduction/csp-directives)
* [frame-src](/en/docs/web-security/policies/content-security-policy/directives/frame-src)
* [worker-src](/en/docs/web-security/policies/content-security-policy/directives/worker-src)
* [default-src](/en/docs/web-security/policies/content-security-policy/directives/default-src)
* [CentralCSP CSP suite](/platform/csp-builder)

## Sources [#sources]

* [MDN, CSP child-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/child-src)
* [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
* [W3C CSP editor's draft](https://w3c.github.io/webappsec-csp/)