mgiuca, would you be the right person to take a look at this?

Note: The Steps to Reproduce are missing the vital step of actually injecting a manifest into the page.

Add after Step 1:

2. Open the Console.
3. Paste: x = document.createElement('link'); x.rel = 'manifest'; x.href = 'https://attacker.com/manifest.anything'; document.querySelector('head').appendChild(x);

This simulates an XSS injecting a cross-site manifest into the page.

I haven't fully investigated this but it seems to be WAI according to the Manifest spec [1].

The manifest spec *explicitly* allows manifests to be fetched from another origin. "As with other directives, by default the manifest-src directive is *, meaning that a user agent can, [FETCH]'s CORS permitting, fetch the manifest cross-domain." This default can be overridden by setting the manifest-src CSP header, as detailed in the CSP spec [2].

"""
    Given a page with the following Content Security Policy:

        Content-Security-Policy: manifest-src https://example.com/

    Fetches for the following code will return a network errors, as the URL provided do not match manifest-src's source list:

        <link rel="manifest" href="https://not-example.com/manifest">
"""

[1] https://www.w3.org/TR/appmanifest/#content-security-policy
[2] https://www.w3.org/TR/CSP3/#directive-manifest-src

If the CSP is not working in Chrome, then that is a security problem. (I haven't tested it; it's non-trivial to test.) But if no CSP header is set, then this is WAI.

+mkwst who wrote the CSP spec. Do you know if the manifest-src CSP header is respected by Chrome? If so, this is WAI, but I just wanted to check.

CSP manifest directive works. But I was hoping that Chrome will patch it even if spec explicitly allows this.

In theory, I agree that it's a bad idea to load manifests cross-origin. In practice, though, folks who designed and shipped manifests disagree with me. :)

`start_url`, on the other hand, must be same-origin with the document that's decorated with the manifest (step 6 of https://w3c.github.io/manifest/#dfn-start_url-member). Are we not enforcing that requirement?

Handing back to mgiuca@ since the CSP question is clear, but I agree with the general assertion that it would be nice if we could limit manifests to same-origin contexts. Have the use cases for cross-origin manifests really played out? The only thing I know of is Microsoft's PWA store, but it's not clear to me whether that actually requires the page to assert that their manifest lives on Microsoft's servers?

start_url is enforced to same-origin so that part is good.

#5 I've confirmed that both scope and start_url are enforced. (Thanks also #6.)

So there is nothing implementation-wise the matter with Chromium. Closing as WontFix.

I agree with #5 that cross-origin manifests are a pain. I don't think Microsoft Store apps rely on this (I thought MS was parsing PWAs in the wild, so presumably they don't need to host their manifest on MS servers). However, I imagine that there are a lot of sites using cross-origin manifests (just so they can host the manifest on a CDN).

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot