Comment by makingstuffs
2 years ago
If the widget is in an iframe with a different host the parent documents JS engine has no way of interacting with the child.
2 years ago
If the widget is in an iframe with a different host the parent documents JS engine has no way of interacting with the child.
The parent documents JS engine can replace the iframe with their own that looks the same
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.
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.
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.