3 ms·
The most probable place of attack is at the merchant where a bad guy would simply remove the Stripe JS code or modify the DOM in a way to replace the credit-car
by patcheudor 13y ago
The most probable place of attack is at the merchant where a bad guy would simply remove the Stripe JS code or modify the DOM in a way to replace the credit-card collection form within the merchant same origin. Please reference the PCI DSS. It states that the controls outlined in that document apply to all processing components. A merchant website calling the Stripe JS within the same origin of their domain eg., http://my.ecommercesite.com/payment http://my.ecommercesite.com/payment is a payment component, period. The only way to remove PCI responsibility would be to load the payment page at stripe.com so that the browser URL shows https://stripe.com/.. https://stripe.com/...
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pd...
- MarkMc 13y agoI agree with everything you say. I agree that the most likely point of attack is the merchant's website. I agree encrypting the credit card number in javascript would not remove PCI responsibility from the merchant. But I don't see how that affects the question of whether the merchant should encrypt the credit card number before sending it to Stripe. Are you saying that such a practice would not improve the overall security of the system? Or that there is no need to improve security if the system is already PCI compliant?
- patcheudor 13y agoRight, encrypting it beforehand makes no difference whatsoever & the merchant must consider that they have PCI obligations so long as they host the form within the context of their same origin.