Service-Worker-Allowed can be cross-origin to the script URL.

[mfalken]

I noticed we don't have WPT tests for Service-Worker-Allowed and started upstreaming Chrome's.

While doing that I added test cases for when SWA is an absolute URL, and found that Chrome accepts SWA that is cross-origin to the script URL, since it only looks at the path of the SWA. That seems a bit surprising. For example, this works if run on https://my-origin.com:

// Set the scope to an upper path of the script location
// Response included "Service-Worker-Allowed : https://another-origin.com/"
navigator.serviceWorker.register("/js/sw.js", { scope: "/" }).then(() => {
  console.log("Install succeeded as the max allowed scope was overriden to '/'.");
});

That seems to agree with the spec which has these steps:

1. Let maxScope be the result of parsing serviceWorkerAllowed with job’s script url.
2. Set maxScopeString to "/" concatenated with the strings in maxScope’s path (including empty strings), separated from each other by "/".

I believe that parsing an absolute URL with a cross-origin base URL ends up ignoring base URL, based on results from new URL() (correct me if I'm wrong...).

I think we should error on cross-origin SWA from the script URL though. Firefox seems to be doing this. Here is error output when script URL is same-origin as the scope at resources/empty-worker.js, and SWA was a cross-origin:

Failed to register a ServiceWorker: The path of the provided scope ‘http://127.0.0.1:8001/service-workers/service-worker/resources/this-scope-is-normally-allowed’ is not under the max scope allowed ‘https://www1.web-platform.test:8444/’. Adjust the scope, move the Service Worker script, or use the Service-Worker-Allowed HTTP header to allow the scope.

[aleemb]

@mattto We tripped into a similar issue, however, in our case everything was on the same origin. When doing,

navigator.serviceWorker.register("/js/sw.js", { scope: "/" })

This failed with the error Failed to register a ServiceWorker: The path of the provided scope...

The fix is to add the Service-Worker-Allowed header and seems to trip up quite a few people. Is there any reason to add this header considering the request is not cross-origin?

[annevk]

@aleemb that's off-topic for this issue. It seems like the error message provides the reason (if you can inject a service worker script somewhere we don't want to easily let it take over the entire domain).

[mfalken]

Just checking, @aliams @asutherland @wanderview @youennf @jakearchibald does this change sound good? The proposal is Service-Worker-Allowed: https://cross-origin.com will throw a SecurityError when served on https://example.com/sw.js. The previous behavior is that only the path of the URL matters, so it's effectively the same as Service-Worker-Allowed: /.

The WPT that would change is here: https://wpt.fyi/results/service-workers/service-worker/Service-Worker-Allowed-header.https.html?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned

According to the results, Edge implements the proposed change, and the other browsers implement the current spec.

There is no particular reason for the change, it just seems odd for the value to be a URL whose origin is ignored; if we wanted to do that it should just be specified as a path. On the other hand, if the spec churn isn't worth it, I can just drop this.

[annevk]

I think you should make this change as it's indicative of something going wrong that developers should get to know early on. (I can't quite find an attack angle, but that shouldn't be the bar.)

[asutherland]

Gecko changed to conform to the spec and tests, ignoring the origin, in https://bugzilla.mozilla.org/show_bug.cgi?id=1532303. That said, I think the proposed change makes sense as the pre-patch spec behavior is very silly.

[aliams]

+1 for making the change.