-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show example with sub-resource integrity #167
Comments
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This is a live security concern with the current product |
@fulldecent We don't support subresource integrity because we regularly deploy changes to the script hosted at https://js.stripe.com/v3 (the integrity hash would need to change every deployment). Being able to deploy critical updates to js.stripe.com is a necessary part of what enables Stripe to take on much of the PCI regulatory burden for users. |
So basically, don't publish version update notes and integrity hashes for https://js.stripe.com/v3 because... San Francisco |
Would you reconsider? |
Would be nice to tighten app security, but Stripe CDN is a blocker. 😭 |
Isn't that true for every single project in the world that publishes SRI hashes? Aren't there existing tools to generate SRI hashes as part of the build process? |
Does the statement from above still hold true - also in the light of the upcoming requirement 6.4.3 of PCI DSS V4.0? |
it would be great if we can have a query param that would allow us to specify the version? if no param is provided then you get latest? so we should be able to do a url like: this will allow us to have the integrity tags on our script elements for PCI compliance |
Per request, I am writing to confirm that no, Stripe has not adopted this best practice. PCI DSS v4.0.1 section 6.4.3 now states that Stripes's CDN is unacceptable. Excerpt from the DSS full document (fair use, this is a licensed document): Related blog post |
lol |
I would also like to see an update to this thread. We are unable to continue moving forward with Stripe due to the failure of implementing Integrity checking. It introduces too much risk lmao. |
Thank you for reviving this thread regarding the new PCI DSS v4 requirements. We've carefully reviewed the updated specifications and can confirm Stripe’s products will continue to remain compliant with PCI DSS v4. Specifically addressing requirement v6.4.3, the PCI guidance states that "the integrity of scripts can be enforced by several different mechanisms including, but not limited to" SRI, CSP, and proprietary script or tag-management systems. At Stripe, we employ robust CSP and proprietary script management systems to meet this requirement. While we don't currently use SRI, this aligns with the PCI guidance, which clearly indicates that SRI is not the only way to satisfy the integrity requirement. We remain committed to maintaining the highest security standards and will continue to monitor and adapt to industry developments as needed. |
My understanding is that Stripe replies here when its security interests are at risk (PCI compliance) but not merely when its customers security interests are at risk (SRI compliance) |
Correct me if I am wrong, However my understanding of CSP is that it does not validate integrity. Although rado-stripe is correct that stripe is technically in compliance to PCI in this regard. It is a stretch that this improves integrity. since CSP is essentially resource origin control. It would nice if stripe went above and beyond ensuring the security of their customers opposed to CSP as fulldecent is saying. |
What has the QSA said for this requirement at Stripe? Our QSA is unhappy with the implementation not having integrity on it |
Summary
The README file here shows this example:
That approach is not best practice. Instead, please use an example that includes sub-resource integrity.
The text was updated successfully, but these errors were encountered: