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 merchant’s 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.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Apr 27, 2021 at 8:07

4 Answers 4


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.

  • 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!
    – Acorn
    Apr 27, 2021 at 11:14

... if a bad actor is able to run javascript on your page

That's exactly the point one want to avoid. Iframes allow third-party sides including script to be part of the visible page without having access to the parts of the page outside the iframes served by this specific third party. This is much more safe than embedding a third party HTML (for the form) and script (for form control, like input checks) directly into the main page.

If the iframe and main page come from a different origin, then the Same-Origin Policy will severely limit how they can interact with each other. Contrary to that a third-party script included with the script tag has full access to the DOM and could do everything a same-origin script tag could do.

  • 6
    Oh, I don't think trusting the author of the iframe contents (e.g. Stripe) is the issue here. And with that kind of solution you'll be including some of their javascript to insert the iframe into the page anyway. The worry is someone manipulating the host page and being able to intercept the information that is entered into the iframe. I'm curious as to what ways an iframe limits that ability..
    – Acorn
    Apr 22, 2021 at 18:04
  • 1
    @Acorn Same Origin Policy restricts also access to another direction. You can't do much with popup especially on desktop (and mobile devices getting stricter also)
    – aholbreich
    Apr 22, 2021 at 18:09
  • 3
    Aren't popups and iframes orthogonal concepts? Also what does it matter if you can't manipulate the contents of a Same Origin iframe if you can just replace it?
    – Acorn
    Apr 22, 2021 at 18:17
  • 1
    A faked iframe won't be logged into your PayPal, your browser won't autofill it and it won't be able to show you your name and address even after you logged in. That's suspicious. Apr 23, 2021 at 9:48
  • @knallfrosch This sounds like the real reason. Can you post that as an answer, please?
    – Bergi
    Apr 23, 2021 at 11:06

I'm writing this as an answer because a comment would be too long. But some time ago there was some malware that was used to infect some e-commerce websites, and the malware simulated a fake paypal popup window, or something like that. To check if the window was real or fake, they suggested trying to move the payment popup outside of the browser's window frame: if you weren't able to, then the popup was fake (simulated by malware).

So yeah, if the e-commerce website is infected, then everything in the page can be replaced, intercepted, simulated.

However there's still an advantage to having third-parties process sensitive data (as long as those third parties are trusted and secure). If you process payment data on your server, then you need to be very careful about how you store that data. If your server gets hacked, the responsibility for a data leak is going to be yours. But if you let third parties process the data (directly, via an iframe or a different window), then the sensitive data never touches your server.

In other words, I think that while nothing can protect data on a website if it is infected, third-party processors can at least help protecting past data (data that was processed before the infection, and which never touched your server).

  • 1
    I guess my question is, if you can do nothing to protect data on a website if it is infected, then why go through all the trouble of writing javascript SDKs that insert iframes into a page? How much of it is because that's the PCI hoop we need to jump through, and how much does it actually protect the data?
    – Acorn
    Apr 22, 2021 at 18:11
  • 1
    @Acorn The iframe approach protects against a number of bad things, including the possibility that the merchant will indefinitely store all their customers' unencrypted credit card information in a publicly accessible database, which is the sort of thing that used to happen alarmingly often. It does not protect against the case where the merchant's entire site exists to gobble up credit card information and send it to attackers (either because the site is a trojan horse or it's been compromised), but the protection of the merchant never accessing the data still reduces the attack surface. Apr 24, 2021 at 2:21
  • @reed aha this is interesting. So it serves as a way to make it easier to audit what a website is doing with the data? I was looking at it from the perspective of a compromised website.. a user is very unlikely to right click on a form to check that it is in an iframe. But if we're just wanting to make it clearer that the data is only going to one destination under normal conditions, then a iframe does make that easier..
    – Acorn
    Apr 24, 2021 at 8:27

I ran a small organization's e-commerce operation.

You're looking at it from an in-browser technology perspective, and presuming every organization is responsible for its own security. Small organizations are simply unable to field a competent IT security department, because the bar is pretty high - you have to be pretty big to be any good at all. It ain't gonna happen, it is not an economic reality for small business. And so many competent third parties (like Square, Quickbooks and many others) are ready to give you turnkey solutions.

This turns it into a "risk game" of a different kind. To start with, I treat our website like outdoor conduit - Electrical code requires you treat it as 100% full of water 100% of the time (and use wet rated wire)... I presume my "brochure website" is 100% hacked 100% of the time and I'll never know it.

So I know I am completely overwhelmed by technical risk. I focus on business risk - when the hack is "all over but the shouting", how will "the shouting" go for me?

The most effective way for me to deal with PCI-DSS is to never handle sensitive data on my site at all, except for services like Square which do point-to-point encryption (P2PE) between a potted device and PayPal's servers. My servers will never have any code that handles any credit card data. I would be perfectly happy sending them to <oursite>.ourvendor.com for the retail stuff, but our vendor does not support that and wants iframes. They do have an IT team, so following their professional advice is the best way for us to escape civil liability for a breach.

We take it one step further and don't even have our own merchant account, since that makes us liable for our vendor's failure to comply with PCI-DSS. The sub-1% surcharge our vendor charges for using their account is cheap insurance at our sales volumes.

So it is ultimately not about technical security: it's about civil liability.

  • That's a great answer. I guess there's two different things going on here. There's the practical civil liability issue of complying with PCI. The other side is the (questionable?) technical advantages of using an iframe instead of using your own form and sending the details directly to the vendor (no sensitive data going to your servers). Unless I'm mistaken, the two approaches mean two different levels of PCI requirements. Just trying to separate out the security reality from the security theatre.
    – Acorn
    Apr 23, 2021 at 22:59
  • @Acorn My vendor isn't going to accept a "blind" form submission of CC data from a client it hasn't already interchanged cookies with. They like to ask for payment data at the very end after "checkout", ID/email, and shipping details are worked out. By doing it last they don't need to retain CVV. Apr 24, 2021 at 0:48
  • +1 to the suggestion that this is focused more on organisational risk than anything. I've moved payment forms to an iframe just because it would make it easier to comply with certain regulations that impact things like who has access to servers etc. Apr 24, 2021 at 12:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .