[CSP3] Extending CSP nonces and hashes and allowing the specification of finer-grained directives to accommodate web workers

Dear CSP3 community,

In a recent study, we analyzed and concluded that CSP3 is limited in its expressiveness and applicability to web worker contexts, i.e., shared, dedicated, and service workers.
In particular, the mechanism’s finer-grained elements, namely nonces, and hashes, cannot be specified in policies deployed on workers.
In a follow-up study involving the analysis of millions of workers in the wild,
we found numerous instances of server-side and client-side XSS in these contexts,
involving URL parameters flowing into JavaScript response bodies or the specific importScripts method of workers,
vulnerable messages, web push notifications events, etc.
Among the countermeasures we experimented with, in particular, with a proof-of-concept (PoC) using an HTTPS Proxy that would be a browser supporting our proposal.
Nonces and hashes can be specified as additional attributes when spawning workers or importing additional scripts in their contexts.
The enforcement of nonces and hashes would follow the same logic as for web pages: to be honored,
nonces specified on the workers’ APIs must be present on the worker-src directive (or its fallback child-src, script-src, and default-src directives).
As for hashes, the values of the `integrity` attributes must match the digests of the responses before they are executed.
The same logic would apply to the importScripts API, provided the baseline CSP is the underlying worker’s.
Finally, following and bearing from the current trend in CSP3, which is in the specialization of directives (e.g., script-src-elem and script-src-attr that fallback to script-src in web pages),
the worker-src directive could be specialized into `service-worker-src` (for service workers), `shared-worker-src` (for shared workers),
and `dedicated-worker-src` (for dedicated workers), which all fallback to worker-src when missing.
This proposal is also fully backward compatible, as non-supporting browsers would ignore the new directives.
Yet, the primary intuition is that not all workers have the same capabilities.
Service workers, for instance, are way more privileged than shared workers, who, in turn, are more persistent than dedicated workers.
In the current specification, a weak worker-src directive conjugated with a website with vulnerable workers’ endpoints
allows the attacker to choose the types they would spawn (i.e., more likely service workers to be more impactful).
Developers would then play more cautiously and securely with the different finer-grained directives and restrict the various types of workers accordingly.

We have working demos where we demonstrated the feasibility of all these features from a browser and developer perspective.
We would be happy to share them with the interested reader. We are pleased to follow up and discuss these materials further.

Best regards,
Dolière