frame-src, worker-src, child-src confusion

[AliceWonderMiscreations]

My interpretation of CSP level 2 was always that child-src applied both to the (at that time) deprecated frame-src context and added web workers. I personally only use one web worker and it is served from 'self' so I never ran into a policy violation that suggests otherwise.

MDN documentation suggests worker-src looks to now deprecated child-src if worker-src is not defined (and then default-src if child-src not defined) and that makes sense to me given that child-src covered web workers in CSP level 2 - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/worker-src

But https://w3c.github.io/webappsec-csp/#examples indicates that worker-src falls back to script-src if not defined.

Is that a typo or is MDN wrong? MDN spec makes more sense to me personally as far as creating a policy that works as intended on both level 2 and level 3 implementing clients.

[annevk]

I think it's worker-src -> script-src -> child-src.

[Malvoz]

@AliceWonderMiscreations

I'm not sure if MDN changed it's description on the fallback behavior since you read it, but it now describes the fallback behavior as (if worker-src absent) to look for: child-src -> script-src -> default-src (and that Chrome 59 and higher skips the child-src directive).
Edit: Never mind, that is what you wrote.

I believe the awkward fallback-behaviors are to ensure compatibility with the rapidly changing spec (e.g. worker-src was introduced later). You should only have to set worker-src which ultimately falls back to default-src if absent.

Fetch directives

frame-src, child-src (deprecated) and worker-src are all fetch directives, all fetch directives falls back to default-src.

[zbjornson]

This is indeed confusing and conflicts with WHATWG's spec.

---

WHATWG lists child-src, script-src and worker-src as the CSP directives for workers (ref). See whatwg/fetch#528 and the linked issues. They seem intent that it's worker-src > script-src > default-src.

---

Section 6.6.1.11. Get the effective directive for request of this spec switches on the whatwg destination, which is worker-src. Section 6.1.13. worker-src has no specific fallback provisions, which implies default-src is the only fallback.

However, 6.1.11.1. script-src has steps for handling resources with worker-src effective directives.

[annevk]

To be clear, the table in the Fetch Standard is non-normative, but we should strive for it to be accurate. When there's a conflict with that table though, CSP is correct and the table is wrong.

[zbjornson]

There still doesn't seem to be a way in CSP to reach the worker-src conditions in 6.1.11.1 though, unless I'm mistaken?

[annevk]

I'm not deeply familiar with CSP's algorithms. @andypaicu or @mikewest can hopefully clarify this.

[andypaicu]

You're referring to this algorithm, yes? https://w3c.github.io/webappsec-csp/#script-src-pre-request

If so, the way it works is this:

1. https://w3c.github.io/webappsec-csp/#does-request-violate-policy will call ALL directives in the policy.
   Most of them will simply return allowed since they don't apply to the request.
2. the script-src will return allowed if worker-src is present and this is a worker request.
3. if worker-src is not present script-src will take over (note: script-like also includes worker destinations).

[zbjornson]

@andypaicu that's it, thanks. I missed the part about the request calling all directives and was caught up in 6.6.1.11. Makes sense now.