Information Security
javascript pci-dss pci-scope iframe e-commerce
Updated Sat, 16 Jul 2022 10:16:03 GMT

How does collecting sensitive data using iframes increase security?

So this approach seems to be rather popular, particularly among payment processors that provide javascript integrations.

The added layer of security that "fields in iframe" brings also supposedly reduces the level of PCI compliance required.

Verygoodsecurity, a tokenization service that also offers forms for sensitive data collection has a rather unusual approach of using a separate iframe for each field of the form, allowing the developer more control of the integration.

What I was wondering was, what added security does this approach offer and what kind of threats does it mitigate compared with just sending the data to the trusted 3rd party via a web request?

Am I wrong in thinking that if a bad actor is able to run javascript on your page, then they would be able to intercept the users actions, regardless of iframes, or is that not the case? Can keypresses be intercepted? And if not, they could just strip out the iframes..

Is it possibly just to make it a little less easy to get at the sensitive data? Maybe it would prevent a non targeted attack, like just listening for anything that looked like credit card details..

Quotes from PCI standards:

iFrame provides sandboxing to isolate content of the embedded frame from the parent web page, thus ensuring that information is not accessible or cannot be manipulated through various exploits by malicious individuals.

but then..

If an attacker has compromised the merchants website, however, they can create alternative content for the frame, which then allows completion of the payment process as well as creation of a copy of the cardholder data for the attacker.


You ask a great question and the technical reason that iframes add a layer of security is covered in many of the above answers. However, you also correctly observe that if an attacker has access to the parent page's contents and can insert their own JavaScript, then they can create a dummy payment form above the real iframe and 'trick' the customer into entering their payment card data into the attackers form, and so you asked the question of whether this is 'security theatre' (or perhaps compliance theatre).

But the case of a fake-frame, because the attacker has no access to the data in the real iframe which hopefully will contain a 'secret' token from the payment service provider (PSP) the attacker will, once they have exfiltrated the customer's payment card data, be unable to complete the transaction by posting it back to the PSP because they don't have that token. The transaction will fail, and typically the attacker generates a failed transaction message and then lets the customer interact with the 'real' iframe.

Because transactions fail, merchants are able to detect the fake-frame attack, whereas the alternative with no frames involved is much harder to detect. Using an iframe from a PSP makes it much harder for the attackers to code and allows detection because of the number of failed transactions. It is not security theatre, but it is also not perfect. However, it does make the attack harder and more detectable - reducing risk.

Personally, if I ran an e-commerce website, I'd use the option that most PSPs provide which is to entirely redirect the customer to the PSP's own payment pages. Again, not 100% secure because an attacker can always poison the redirect, but much easier to detect and so further reduces risk.

Ignoring PCI DSS compliance for the moment, the use of Content Security Policy (CSP) and Sub-resource Integrity (SRI) combined with an external synthetic-user detection service are your real friends in defeating e-commerce skimming attacks.

Comments (1)

  • +0 – Interesting point about making tampering more obvious, and the idea that someone skimming details may want to avoid breaking the normal functionality of the page to avoid detection. I hadn't considered that! — Apr 27, 2021 at 11:14  

External Links

External links referenced by this document: