CentralCSP
PoliciesContent-Security-PolicyDirectives

child-src

The CSP child-src directive is a legacy fallback for frame-src and worker-src. Prefer those two directives instead.

Last update:

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 for frames, worker-src for workers) and 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:

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

Fallback chain

child-src itself falls back to default-src, and it acts as the fallback target for two other directives:

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

child-src takes a space-separated source list combining keyword sources, host sources, and scheme sources:

ValueStatusDescription
'none'✅ GoodBlocks all frames and workers.
'self'✅ GoodFrames and workers from the page's own origin only.
embed.example.com✅ GoodA specific host, applied to both frames and workers.
https:❌ RiskyAny HTTPS host can supply worker code through the fallback.
blob:❌ RiskyFlows to workers through the fallback and widens what can run as script.
*❌ RiskyFrames and workers from anywhere. Never matches data: or blob:.

Nonces and hashes do not apply.

Examples

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

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 and workers to 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

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 and frame-src lets you keep workers at 'self' while still embedding the third-party frames you need. The CSP evaluator flags where a policy relies on the legacy fallback.

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

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 and worker-src directly so embedded frames and executable worker code each get their own rule.

Reporting

When a frame or worker load is blocked, the browser sends a csp-violation report; 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

child-src is supported in every browser that implements CSP. The split into frame-src and worker-src is also widely supported, so prefer those.

See also

Sources

On this page