[hn_throwaway_99]

The fact that the card number data is stored at Stripe doesn't matter that much. As parent commenter says, the card numbers are still visible on terminal.shop's network because it all goes over their SSH connection.

For most websites that use the Stripe widget, the website owner can never see the full card number, because the credit card number entry fields are iframed in on the page. That means website owners in this scenario are PCI compliant just by filling out PCI SAQ A (self assessment questionnaire A), which is for "Card-not-present Merchants, All Cardholder Data Functions Fully Outsourced": https://listings.pcisecuritystandards.org/documents/SAQ_A_v3...

But that questionnaire is only for merchants where "Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party(s) to handle all these functions;" For e-commerce merchants who CAN see the card number, they need to use SAQ D, https://listings.pcisecuritystandards.org/documents/SAQ_D_v3.... This includes additional requirements and I believe stuff like a pen test to be PCI compliant.

[jjeaff]

it's been a while since I did the full pci compliance rigamarole, but I don't recall it being that difficult. you basically just answer a bunch of questions correctly about how you are transmitting and storing the data using sufficient encryption and then they run some automated pen tests on your site and then you are done.

[alt227]

>run some automated pen tests on your site and then you are done

Haha you are obviously choosing to hide some pain away from your memories.

I agree that you run automated pen tests, but then securing up all networks servers with the results of those pentests can be incredibly time consuming and awkward.

[jjeaff]

I suppose on a very complex system, that could be a big deal. But I think the last site I did it on was running on AWS so all ports were closed unless I specifically opened them for a specific purpose and it was just a few tweaks I had to make to pass. I normally only have 80 and 443 open to the outside world.

[ansc]

It's expensive.

[throwaway5371]

you can say the same about the widget, as the website embedding the widget has access to the document's keydown

[makingstuffs]

If the widget is in an iframe with a different host the parent documents JS engine has no way of interacting with the child.

[rhysmdnz]

The parent documents JS engine can replace the iframe with their own that looks the same

[hn_throwaway_99]

To be clear, that is exactly what the PCI SAQ A-EP questionnaire covers. It basically says "You don't access any cardholder data, but you own the page that hosts/redirects to the third party processor (like Stripe)." So the questions in the SAQ A-EP are about ensuring that your page has enough basic security (at least as can be asked in a questionnaire) to prevent hijacking, whereby a nefarious script (through an XSS vulnerability for example) sends them to a site to phish their cc details. Note that a decent content security policy on your website can prevent most of these types of problems.

[RobMurray]

That wouldn't help, at least with my bank in the UK, the iframe just shows a message to open the mobile app to approve the payment. The payment details are then shown in the app, you don't interact with the page in the iframe at all.

[hn_throwaway_99]

But that would still require an eagle-eyed consumer, which (coming from experience working in the fintech space) is quite rare.. I.e., you may know the iframe is supposed to just ask you to open your mobile app, but I think the vast, vast majority of users wouldn't think twice if that iframe had been hijacked and instead asked them to enter their credit card information directly.