I recently tried to update my credit card information on a site that is served over HTTP. Even after login the site stays on HTTP!

I noticed that Chrome would not let me use the saved credit cards for this reason.

Upon contacting the company they replied that the payment window itself is hosted by the payment provider, and served as a modal via HTTPS.

I just can't see how this is safe, because anyone could easily do a man-in-the-middle attack and replace the modal with their own form and retrieve the card information.

I then contacted the payment provider, but they too had no problem accepting HTTP referer and callback addresses to/from their payment page. I came up empty when looking at the PCI compliance requirements, because they do not describe requirements for hosted solutions, as in this scenario.

EDIT: I made this screen capture to add some clarity to the scenario: Man-in-the-middle demonstration

The keys are logged on the login form and the "secure" credit card form is replaced by an image the second time it is loaded.

  • 3
    If the login is over HTTP, then their security is broken regardless of what their payment window is served over. A MITM can just steal your password and login as you. Unless of course the payment window uses entirely separate credentials.
    – Ajedi32
    Dec 12, 2016 at 16:37

3 Answers 3


There is no "modal window" there is content which might be intended to contain an iframe pointing to a secure URL, but since it is invoked from insecure javascript and html it is vulnerable to modification. And as an iframe the user does not get to see all the meta data displayed in the browser chrome when you navigate to a secure URL.

Not only is this insecure it is visibly insecure.

  • Yeah, going by the linked video in the OP's edit it's clear there's no "payment window" here at all. The payment form appears inline on the insecure HTTP page, which is obviously insecure.
    – Ajedi32
    Dec 12, 2016 at 20:59
  • @symcbean,I believe there is a modal window. "A modal dialog is a window that forces the user to interact with it before they can go back to using the parent application." from What is a Modal Dialog Window?
    – user133193
    Dec 12, 2016 at 21:32
  • @Ajedi32 The payment form is in fact served over https in an iframe. It is impossible to determine where and how content is loaded based on a screen capture.
    – user133193
    Dec 12, 2016 at 21:35
  • 2
    @Searcher821 My objection is to the term "window", which to me implies something at the OS-level. If the payment form were actually in its own browser window, Lie's answer below would apply. In this case though, what's really being displayed is, at best, an iframe inline with the page, which is equivalent security-wise to a form POSTing to an HTTPS page. That is to say, it's completely useless against active MITM attackers, but effective against passive monitoring attacks.
    – Ajedi32
    Dec 12, 2016 at 21:43
  • @Ajedi32: Point taken. Modal dialog is probably a better wording. I also agree that it must be completely useless. I think this may be the correct answer then.
    – user133193
    Dec 12, 2016 at 21:49

No, this is not secure for two reasons:

  1. The main page could be intercepted and malicious JavaScript code could be injected that steals whatever data you're entering into the payment form.
  2. The main page could be intercepted and the code that opens the payment form could be modified to load a fake payment form from another source.

Note that the second point also applies to separate payment pages that are linked from a page that's loaded over HTTP, in which case it's possible to change the link to a fake page. Although in that case you can see the URL of the payment page and check whether or not it's secure and legitimate (this is why it's important to always check the URL of the page where you're actually entering your payment information). In the case of something like what you describe you can't see the URL of the payment form so it could be loaded from a malicious URL and you wouldn't even know where it's coming from.


Using an HTTPS modal dialog can be secure provided that:

  1. The card update form that you enter your credit card number and CVC is hosted on the payment provider's site
  2. The payment page displays the merchant's name, amount of payment, and possibly the itemized purchase and is hosted on the payment provider's site
  3. The browser's URL Bar of the payment processor's pages are visible and shows HTTPS with a Green EV Bar
  4. The user checks the green EV bar on the payment processor's pages
  5. The user trusts the payment processor whose identity is shown in the Green EV Bar

If all these conditions are satisfied, then it doesn't really matter for credit card security if the merchant's shopping cart website is unencrypted. There can still be other security issues though, like privacy of purchased items, but I believe that's out of scope of this question.

  • 2
    How can the URL bar of a modal window be visible? The only way to get "modal windows" in browsers is some AJAX stuff or iframes.
    – Josef
    Dec 12, 2016 at 14:36
  • 3
    I don't think this answers the question. An HTTPS page invoked by an HTTP page is pretty unsafe whether you can see the address bar or not.
    – billc.cn
    Dec 12, 2016 at 15:29
  • 1
    @Josef: I was referring to a popup window with visible URL bar. A payment page in an iframe is unsafe due to cross frame scripting, which violates point 1. It partially violates point 3 and 4 as iframe lacks URL Bar, however you can still see the HTTPS status using Inspect Network tool, for most people these points are essentially violated.
    – Lie Ryan
    Dec 12, 2016 at 16:21
  • But there are no modal popup windows that websites can open in browsers.
    – Josef
    Dec 12, 2016 at 16:29
  • 1
    Unfortunately, I think assumption #4 is unlikely to be true in practice.
    – Ajedi32
    Dec 12, 2016 at 16:40

You must log in to answer this question.

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