Static version of pay.js for PCI compliance

[Kevin-McCormick-eStar]

Is your feature request related to a problem? Please describe.
PCI v4 mandates more stringent integrity checks on scripts being loaded into payment pages

Describe the solution you'd like
A static version of pay.js that can be either hosted locally, or on a cors enabled cdn allowing for SRI checks

Additional context
This was mentioned in this issue as a comment

[dmengelt]

Hi @Kevin-McCormick-eStar We are aware of the PCI v4 requirements. Will update this issue once we have more clarity...

[tristan-littlepay]

I want to escalate this. The new requirement - verifying the integrity of all scripts - is mandatory by the end of March. Can you @dmengelt give us an update on the process and potential solution? Other helpful measurements would be to publish a list of valid SRI hashes and versions or even a changelog of the pay.js library.

[dmengelt]

@Kevin-McCormick-eStar / @tristan-littlepay

I'm very sorry for the late reply. One potential solution for this is to iframe the Google Pay integration:

And then work with the sandbox attributes for further isolation. For example:

<iframe
  src="https://cdn.merchant.com"
  allow="payment"
  sandbox="allow-scripts allow-popups allow-same-origin allow-forms">
</iframe>

Like this, the inclusion of pay.js should be independent from your parent page where you (most likely) accept PCI relevant data (card number, cvv)

[ajones8602]

We also are in need of a static version of pay.js in order to PCI compliant. Would be nice to see this come to fruition.

[Kevin-McCormick-eStar]

@dmengelt Does this mean that you will not be working on a static version of the script? I can't see many of our clients being willing to pay for the extra development the iframe workaround would entail

[jack1012t]

Joining the fun here - I am commenting to follow since I'm seeing content security policy violations from https://pay.google.com/gp/p/js/pay.js:

pay.js:304 Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-5RzhhNYzrZZHMOsSAzxctw==' https://fonts.googleapis.com 'sha256-5FP2izv130oNVgmku6lP72ClsWDjrp+IP6/fWsduhWE=' 'sha256-NRhyTE9KfaG3K8xul9NNBuk2j3aHpmifclB1jFj/A34=' 'sha256-Wt8QHXy+olUfeL2VUOWwihypwc2gTYTEG3ajdqGA+aU=' 'sha256-FLRm7r7i00KpcCzm9QqCmHRlbKiP/NG4RVhxYPLrMZQ=' 'sha256-yEOTj/M/OAU9JsDyqzbq0QURBLuWU7guxlIpNrT2oxI=' 'sha256-HMUZyhqSpKfJ6IXH35LOA2eUwNFuyA6/+38x+JXR5xQ=' 'sha256-+9ojJCU9UifKWweImjUNmV6RBDSg9+d7SqM3pRGyh/U='". Either the 'unsafe-inline' keyword, a hash ('sha256-yEOTj/M/OAU9JsDyqzbq0QURBLuWU7guxlIpNrT2oxI='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

As you can see above, the mentioned hash is already included in the style-src policy list. Are there any plans to fix this?

Key from the above CSP violation: Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present

FWIW, the button UI does not break, and I'm still able to process the payment, but it's sure ugly to have CSP violations in the browser console!

PCI v4 as mentioned requires amongst other things, internal reporting on CSP violations. I've put an exception in my CSP report for https://pay.google.com/gp/p/js/pay.js for the time being.

pay.js line 304:

it sure seems that the old textContent fix would work here, it seems maybe the issue is the innerHtml?

Please advise

[jack1012t]

@dmengelt do you have any updates here? Thank you!

EDIT: tagging others, and wondering if we should reach out to Google bughunters

Currently it seems the only way around this is to accept the CSP errors in the browser console, or you have to sacrifice security by adding unsafe-inline or unsafe-hashes to your style-src CSP header to resolve the console errors. Both "solutions" have their drawbacks, but I'll accept the console errors over compromised security any day.

I've added a filter to my CSP violations reporting logic to ignore errors from this source, so that we're not getting alerted to problems that are beyond our scope.

Please ping back here if this is still an issue for any of you: @Kevin-McCormick-eStar @ajones8602 @tristan-littlepay

[Kevin-McCormick-eStar]

Please ping back here if this is still an issue for any of you: @Kevin-McCormick-eStar @ajones8602 @tristan-littlepay

Yes this will definitely be an issue for us going forwards, especially if the button itself is throwing errors. As I mentioned, none of our clients are likely to be willing to pay for the development involved in the iframe workaround, they are much more likely to just drop it as a payment method.