This was true in other case I copied the error from. Not sure yet if true here.

My testing shows that

• module workers respect worker-src. So if you set a CSP: worker-src 'self' you can load a module (which is always same origin), then it can import further same origin modules, but NOT cross-origin modules.
• classic/script* workers do not respect worker-src. So if you set a CSP: worker-src 'self', a wokrer script can import a cross origin script using importScript .
• classic/script* workers do respect script-src, So if you set a CSP: script-src 'self' this will block a worker script loading a cross origin script.

It sounds like you're saying that worker-src controls the scripts that a worker can load? Not the source of the worker itself? In that case isn't the example here wrong: https://w3c.github.io/webappsec-csp/#directive-worker-src ?

@wbamberg I have updated my note above to state more clearly what testing shows.

But to summarize, I'm saying that

1. worker-src affects the scripts that can be imported into a module worker, but not the scripts that can be imported into a classic worker.
2. worker-src seems to be pointless, since if I specify Content-Security-Policy: worker-src https://example.com/ neither a module or classic script at that address will load. ONLY same-origin modules ever load.

Clearly the intent is that the worker-src allows control over where module scripts can be loaded from, and "perhaps" also where they may load. But that's not what my testing is showing. Of course my testing might be wrong.

Hoping to get some clarity from Jake in https://github.com/mdn/content/pull/42073/files#r2666249206

As in me? Which part? I think GitHub is being unhelpful and hiding something

Hamish is out for the next two weeks but I promised to try to get this PR merged if I could :).

The question we have is, when a page loads a worker script, does the worker have to be same origin with the loading document? The page for the Worker() constructor says:

This script must obey the same-origin policy.

...which seems to me a curious thing to say (I mean, everything has to obey the SOP, it's a browser policy, so what is the substantive force of this statement?). We weren't sure whether this means "the script must be same origin with the loading document". Hamish's tests indicate that it does have to be same origin.

But that raises further questions, such as, what is the worker-src CSP directive for, then? The spec for worker-src even has an example of how you would use the directive to block workers from a different source, and why would you need that if the worker needs to be same origin?

So we thought we could ask you since you probably know.

Yeah the root worker script needs to be same origin. However, scripts from other origins can be loaded via ES imports and importScripts. I guess that's what worker-src is for

OK, thank you! Then it looks like Hamish's tests are all right.

I guess that's what worker-src is for

That is still odd, because it's not what the example from the spec is showing: https://w3c.github.io/webappsec-csp/#example-fd6c5849. But I'm going to let it go now :).

Thanks @jakearchibald and @wbamberg . It is a relief to know that all the testing was not just "wrong". I'm OK to let this all go for now - as you say it is a bit odd but it is what I saw.

I guess this has the same meaning (and constraints?) as https://developer.mozilla.org/en-US/docs/Web/API/RequestInit#credentials, where it is all described more fully (including saying what credentials are). Maybe link there and say this?

Yes. Done in 1837809

This controls whether a module worker sends credentials when it imports a cross-origin module.

This is ignored for classic modules. They send credentials for same-origin imports. They generally won't send them for cross-origin imports - it isn't under the control of the interface. They might if the remote server allows it.

Am I right to understand that these 2 paras are exclusively about scripts that the worker script itself loads? i.e. they're not about loading the worker script itself (since that's always same-origin)?

If so then I think you ought to have a heading like "Loading scripts from a worker" or something, to make this very clear.

OK

I don't really understand this. It seems to be saying: because classic workers are fetched in no-cors, then they can make cross-origin requests without CORS headers (btw "not blocked by CORS" is not a good way to put it, CORS doesn't block anything, it only unblocks things).

But is that right? Why does the mode a script was fetched in affect the mode of the requests it makes? I don't think this is true. If a resource is fetched in no-cors then the fetching of it has certain attributes, but I don't think that "carries over" to the requests that it makes, does it?

@wbamberg So yes, I am saying that classic workers are fetched in no-cors mode. My understanding was that this mean't that any requirements of CORS are ignored - the request will succeed as if CORS headers were not set.

I did not mean to make any statement about what mode a classic script would import its scripts using - I just tried to make clear that a classic script uses importScripts() to load further scripts, and not import.

You're right that we can't draw any assumptions about this. That said, that is what my tests showed. I'll try check again on Friday.

@wbamberg So yes, I am saying that classic workers are fetched in no-cors mode. My understanding was that this mean't that any requirements of CORS are ignored - the request will succeed as if CORS headers were not set.

But that's only relevant for cross-origin fetches, right? So if fetching a worker has to be same-origin, it's irrelevant. Put another way, the doc says:

Because they are fetched in no-cors mode, cross-origin requests are not blocked by CORS,

...what are these "cross-origin requests", if fetching a worker has to be same-origin?

Cross origin import requests made by the worker.

I have addressed in https://github.com/mdn/content/pull/42073/files#r2674625053

It sounds like you're saying that worker-src controls the scripts that a worker can load? Not the source of the worker itself? In that case isn't the example here wrong: https://w3c.github.io/webappsec-csp/#directive-worker-src ?

We would expand this with other differences if we knew them.

@wbamberg I think this is ready for another look.

Unfortunately I ate the commits while trying to create a version where it would be easy to be determine the changes.

Since last you looked I have addressed your comments, including adding this section on importing scripts and the credentials.

Essentially I think my testing provides a consistent story (or or less) - workers must be constructed with a same origin script/module. The credentials apply to the modules that are imported by a module worker (but not a script worker, over which you have no control via the API).

The remaining inconsitency is this section - why would you use worker-src if you can't import the main script cross-origin, and why is it ignored for scripts. However this is what my testing shows about CSP. If we question this too much, we could drop this line. Or just put it in, and hope to tidy later.