Open AliceWonderMiscreations opened 6 years ago
I think it's worker-src -> script-src -> child-src.
@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
Edit: Never mind, that is what you wrote.worker-src
absent) to look for: child-src
-> script-src
-> default-src
(and that Chrome 59 and higher skips the child-src
directive).
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.
frame-src
, child-src
(deprecated) and worker-src
are all fetch directives, all fetch directives falls back to default-src
.
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 https://github.com/whatwg/fetch/issues/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.
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.
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?
I'm not deeply familiar with CSP's algorithms. @andypaicu or @mikewest can hopefully clarify this.
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).
@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.
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.