The other day, there was a web developer mailing list thread about a fundraiser page.

One person noted that the page with the credit card form was HTTP, not HTTPS.

In response, one person said that since the target of the form was HTTPS, it's not a problem

Nah, the form's submitted via https, served by Stripe. The site itself is http, though...

However, someone argued in response that that is not enough

You have not established that the form is secure. A MITM may modify the HTML in the response for http://example.com/ to replace the form's "action" attribute.

The website in question has since changed such that going to http://example.com takes you to https://example.com instead, so it's (hopefully) secure now, but I want to know for future reference.

Is a credit card form being on HTTP, but the target being HTTPS, a security risk for MITM attacks?

  • 1
    MITM won't be needed.If the website is using http simple packet capturing using wireshark will reveal your data.
    – Shurmajee
    Commented Mar 1, 2013 at 8:47
  • 5
    Financial data on non-https? I just swallowed an apple whole :|
    – Luc
    Commented Mar 1, 2013 at 20:54

4 Answers 4


Yes, that last someone is correct, in addition to encryption (confidentiality) HTTPS gives you the assurances that the form is coming from where you think it is (authentication), and that it has not been interfered with in transit (integrity). Without HTTPS the form could be modified by a MITM as described.

It'sNot using HTTPS for this is simply bad practise (since the user is often the weakest link), when entering important data the user should just expect to see HTTPS (padlock/green bar/whatever) at every step, no exceptions.

Most browsers will warn by default if you POST from a HTTPS page to a non-HTTP URL, but they don't all clearly indicate that your data is being sent securely in the opposite case. Lack of HTTPS also means that site won't be using "secure" cookies.

See also: Is posting from HTTP to HTTPS a bad practice?

Properly addressing this issue requires HTTP STS (RFC6797), though a boot-strapping issue remains with first HTTP requests in most cases.

A similar issue is the practise of using an iframe to a HTTPS site within a HTTP page, e.g. 3rd party credit card service. In this case, though the form and the post are HTTPS, there's no assurance of integrity in the non-HTTPS content containing the iframe. The browser doesn't show the form is HTTPS (at least not in the normal way, if at all), so this also violates the expectations of a security conscious user.


A man in the middle could easily manipulate the post target, so it doesn't point to the secure HTTPS url anymore. The user cannot see whether the target is secure (without looking at the HTML code), so he just has to believe that the POST target is secure.

This scheme of an unsecure HTTP form calling a secure HTTPS url, is always vulnerable to SSL-strip.


While some of the answers are indeed helpful, they all have neglected mentioning a very important aspect, malicious code injection.

A MITM is able to modify the page served to you over HTTP, thus making him able to inject malicious Javscritpt that, for example, waits until you hover over the submit button and makes an Ajax POST to the attacker's server sending the form information. This is basically what the Tunisian government did to harvest Facebook credentials of dissidents.

So there are, as far as I know, two security problems for serving forms over HTTP (well, they're actually one, but can be exploited in two different ways):

  1. The attacker changing the submission target (the action field)
  2. The attacker injecting Javascript code that sends the form data to a 3rd party.
  • 1
    It is worth noting that under some circumstances, it may be possible for the latter attack to be carried out even against an actual SSL page if the page isn't designed securely. Commented Mar 1, 2013 at 20:41

Ok, to be clear, you should NOT do this as a site developer, but if you need to work with a site that behaves this way, my answer is designed to say what CAN be done safely. Basically you can't trust anything on the page itself, all you can trust is that if the SSL cert resolves, then the post is talking to the legitimate server for the URL that it claims to be. You have to manually validate that it is sending to that URL and that it is the appropriate URL. This can only be done if the response is going to the same top level URL that served the page since you know you are trying to connect to that top level domain.

As long as the user was verifying that the post target was the intended server and that post connection was HTTPS and that there was no scripts that could alter the content present on the page and the browser doesn't send over an HTTPS link that doesn't have a valid cert for the URL being sent to, then the form would be perfectly secure. Note that you could only know the intended server if it is posting to the same TLD as the page is hosted from. You wouldn't, for example, know if www.bob.com telling you to submit the form to www.bobspayments.com was valid. It is also possible that if the same information submitted to two different services would do different things, then a malicious user might be able to make use of that. The problem is that a user won't do that. It does protect against passive sniffing, but won't provide verification to the user that the site is legit which SHOULD (but probably won't in many cases) raise concern by the user.

An active MITM attacker could simply change the page to return the information to them, but then again, this could be done even if the page itself was HTTPS since many users wouldn't notice if it was actually an HTTP page that was returned, so I'm not sure if there is really a significantly larger threat from an active MITM either since in either case.

The real problem would be the user experience and the fact that it shows up to the user as the page not being secured, so HTTPS is still preferable for the entire page for that reason. To clarify, there is a lot that can go wrong if the page contents are not authentic, so proving authenticity is preferable, but as long as information is actually submitted over SSL, then it will be protected. The problem is guaranteeing that it will be without manually reviewing page code.

  • -1 No, even if the user checks the submission target (action field) the form is not perfectly safe. Please check my answer.
    – Adi
    Commented Mar 1, 2013 at 19:56
  • @Adnan - added the requirement that they would also have to check for scripts altering the link on the page. My point is that provided a user verifies the behavior of the page, then sending data over an HTTPS link would be secure as long as the browser only sends if the link is trusted. I suppose another attack would be to masquerade the HTTPS and hope it won't report the invalid cert. Commented Mar 1, 2013 at 20:05
  • Still not enough. The user should know the value of the action through a safe channel before loading the page through HTTP so they can compare the two values and make sure that the form is submitted to the correct URL. For that to happen, the user should call the company running the website by phone and ask them for the correct URL, or should load the website with HTTPS, learns the correct value, and then load it with HTTP and compare the value. Come on! Does that make sense for you?
    – Adi
    Commented Mar 1, 2013 at 20:11
  • @Adnan - HTTPS doesn't help verify that the URI is right. If I'm going to blah.com and I submit something via an HTTPS post to blah.com then for the SSL session to be valid, it has to actually be blah.com. If blah.com wasn't the right place and I was supposed to be at bob.com, then HTTPS isn't going to help me. The SSL certificate of the post address validates that it is the company. This is true regardless of if the page is loaded via SSL or simply the post submitted via SSL. Commented Mar 1, 2013 at 20:13
  • By using HTTPS I meant this: Accessing the page containing the form with a valid HTTPS session -> the user gets the correct value for the action field. Unless the user does that, there's no way for him to detect any manipulation in the action field in the HTTP-served page. It's a common practice for websites to submit payment forms to another payment processor. Please take a couple of minutes and read through your answer and the comments.
    – Adi
    Commented Mar 1, 2013 at 20:18

You must log in to answer this question.

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