It's not at all clear to me how the payment app is actually being installed, and which page's policy should apply. If we're installing a Service Worker for some other origin, then it's not clear to me that the initiator document's `manifest-src` should apply, as it doesn't actually affect the given origin, but I also don't really understand the capabilities that payment handlers expose. Perhaps they should be governed by `manifest-src` (though that would potentially break sites that set `default-src` today. *shrug*).

+Rouslan: Can you help us understand how Payment Handlers ought to be integrating with CSP? Who's responsible for the requests?

I think Security_Impact-Stable is wrong. This bug doesn’t affect M67 but affects M68

rouslan: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Medium -> Low as a "partial CSP bypass" per https://chromium.googlesource.com/chromium/src/+/master/docs/security/severity-guidelines.md

What do you mean by partial CSP bypass? And what do you consider a full CSP bypass?

Hi, I do not see the necessity of integrating CSP for payment method manifest and JIT here. Could you provide details of the risk not applying it?

Payment method manifest url is resolved through payment method name plus its header (Link: </pay/payment-manifest.json>; rel="payment-method-manifest").

For JIT:
Web app manifest url is from the payment method manifest. And we are requiring payment method and web app manifest url must from the same site (top level domain). Web app manifest url, service work url and registration scope must from the same origin.

Hmm, maybe if you never allow payment app installation without `Link: </pay/payment-manifest.json>; rel="payment-method-manifest"` response header than it seems okay (I thought <link> tag also works in non-JIT cases, but it doesn't).

But security checks for JIT seems weak. I will report another bug when I confirm this.

See  issue 863974 

Can you cc me on that bug? I have no permission to access it.

JIT PH do always require <link> tag for the payment method manifest.

Non-JIT PH (already installed PH) do not check payment method manifest if it is from the same origin of the payment method for efficiency.

Sorry, I don't have permission to CC you... I can only report bugs or write comments...
But CSP issues seems not risky, indeed.

Okay, thanks, I will wait for somebody else to cc me on that bug.
Close this bug for now.

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