I'm currently volunteering at a nonprofit. While researching something unrelated, I noticed that a $sisteragency was using an embedded iFrame to accept online donations. While the frame's source uses HTTPS, the page it's on is HTTP.

$sisteragency uses third-party CRM software to handle donations, provided by $crmcompany. $crmcompany claims to be PCI compliant, but its instructions seem to be built around adding the iFrame to an insecure page. Its knowledge base contains a suggested message to show users that boils down to, "Even though you can't see the padlock or https in the address bar, the part of the page that captures your payment information [the iFrame] is secure." Their YouTube page has a video tutorial where they show the iFrame (with an https src) being added to an http page. Their site even has step-by-step instructions for responding to PCI compliance inquiries from a payment processor (as in, exactly what to enter in each field).

This all seems really shady to me. Couldn't a man in the middle attack modify the iFrame's src, since the containing page is http? Despite $crmcompany's claims, isn't $sisteragency also responsible for PCI compliance ($crmcompany says it is responsible for its clients compliance)? Is $crmcompany being negligent and/or noncompliant by providing instructions for embedded the secure payment system in an insecure page?

Basically, am I right to be so unsettled by all this?

  • This has been answered before here: security.stackexchange.com/questions/38317/… and here security.stackexchange.com/questions/894/… with an emphasis in one of the answers on those links: "this is explicitly against PCI-DSS requirements. See ‘Navigating DSS 2.0’ requirement 4.1 - When using SSL secured websites, ensure “https” is part of the URL"
    – munkeyoto
    Commented Apr 28, 2016 at 15:28
  • I did see that question, but I'm trying to figure out whether $sisteragency or $crmcompany is more at fault here, and how much of an issue this is.
    – Sigvaldr
    Commented Apr 28, 2016 at 15:35
  • It is a big issue because it is not allowed per PCI period. $sisteragency is tasked with the processing / link so they're at fault, and would have the most to lose in either event.
    – munkeyoto
    Commented Apr 28, 2016 at 15:55
  • Should we advise $sisteragency to use HTTPS on that page, or to dump $crmcompany for providing the instructions to embed the iFrame on an insecure page?
    – Sigvaldr
    Commented Apr 28, 2016 at 16:15

3 Answers 3


Using an https iframe in an http webpage only protect against passive attackers.

It is not a good solution because:

  • It doesn't protect against active attacker (they can rewrite the url of the iframe, see sslstrip)
  • The browser can't display a padlock for https (because the main page is not secure)

The only way to handle data securely is with HTTPS on the full webpage:

  • Everything is encrypted to even an active attacker can't read the data or modify it (including links)
  • The user get confirmation from the browser that everything is encrypted (with the padlock)

Note that having that page using https is not enought: The links to that page should be protected to (imagine if the http home page show a an https link "donation", an attacker can rewrite it). So to really protect a website that handle sensitive data (note that by European law, personal data must be protected) the whole website should use HTTPS.

Using HTTPS + HSTS on the full website is the best way to protect a website that must protect some data, even if it is in a few webpage.

(Sorry, I know it doesn't answer about PCI conformance, only about security.)


It's difficult to believe that the $crmcompany is truly PCI compliant with that kind of "secure" iFrame inside a non-secured document setup. Even if $crmcompany is PCI compliant (and I would request a copy of their most recent audit showing compliance), your non-profits are not PCI compliant and are required to be since they take payments through their site (regardless of iFrame). Since the payments appear to be coming through the non-profit's site, they need to be PCI compliant. Additionally, if they retrieve and store any of the PII related to the payment transaction, they are also liable for PCI compliance, and as @Tom mentioned, will need to secure the PII under EU privacy laws.


Consider you are having a insecure site http://charity.com with a secure site https://Securecharity.com embedded in iframe in insecure site.

An user who is using a public wifi (hosted by an attacker with a name "FreeHub" in a coffe shop) and accessing your insecure site where secure site is loaded in iframe. At this point the attackers now has access to the data stream b/w user and outside world(MITM attack).He could be able to see all the data accessed by user in clear text(Only HTTP site).

Since the secure HTTPS site is iframed in insecure HTTP site, there is a chance for

  1. The attacker to insert java script in HTTP site that could log all the key strokes(Key Logger).
  2. The attacker could also redirect the user to some other phisphing site by just changing the inframe src(Since the iframe is embedded in HTTP).

Also, since the hosted site in HTTP, browser wont show a padlock (which indicating the site is Secure). Educated user who has knowledge about HTTPS/PCI wont be ready to enter their payment/card details though your site mentions "Even though you can't see the padlock or https in the address bar, the part of the page that captures your payment information [the iFrame] is secure."Thus it reduces donation to your organisation.

Since it involves with user payment details it is best to host a secure HTTPs site.

You must log in to answer this question.

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