Skip to content
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

Closed
fulldecent opened this issue Mar 24, 2021 · 16 comments
Closed

Show example with sub-resource integrity #167

fulldecent opened this issue Mar 24, 2021 · 16 comments

Comments

@fulldecent
Copy link

Summary

The README file here shows this example:

<script src="https://js.stripe.com/v3" async></script>

That approach is not best practice. Instead, please use an example that includes sub-resource integrity.

@stale
Copy link

stale bot commented Apr 14, 2021

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.

@stale stale bot added the stale label Apr 14, 2021
@fulldecent
Copy link
Author

This is a live security concern with the current product

@stale stale bot removed the stale label Apr 15, 2021
@christopher-stripe
Copy link
Contributor

@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.

@fulldecent
Copy link
Author

So basically, don't publish version update notes and integrity hashes for https://js.stripe.com/v3 because... San Francisco

@The-Hidden-Hand
Copy link

Would you reconsider?

@twistedpair
Copy link

twistedpair commented Feb 9, 2022

Would be nice to tighten app security, but Stripe CDN is a blocker. 😭

@Jamyn
Copy link

Jamyn commented Jul 11, 2023

@fulldecent We don't support subresource integrity because [...] the integrity hash would need to change every deployment

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?

@clnative
Copy link

Does the statement from above still hold true - also in the light of the upcoming requirement 6.4.3 of PCI DSS V4.0?

@wenisman
Copy link

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:
https://js.stripe.com/v3?v=1.2.3

this will allow us to have the integrity tags on our script elements for PCI compliance

@fulldecent
Copy link
Author

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):

Screenshot 2024-08-30 at 19 05 40


Related blog post

https://pcipolicies.com/blogs/news/how-to-comply-with-the-new-pci-dss-requirement-6-4-3?srsltid=AfmBOorb9iXHm9h0HaLbdvE-co1NH3g5hKTWs0REA9ajKgmSboaAFMAy

@fulldecent
Copy link
Author

lol

@austinmarten1
Copy link

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.

@rado-stripe
Copy link
Contributor

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)

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.

@fulldecent
Copy link
Author

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)

@austinmarten1
Copy link

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.

@TheAutisticTechie
Copy link

What has the QSA said for this requirement at Stripe? Our QSA is unhappy with the implementation not having integrity on it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants