Michael Horowitz
Home => Submitting Data
[Formatted for Printing] From the personal web site of  Michael Horowitz

Submitting Data with HTTP and HTTPS

Created: February 27, 2020 | Updated Dec 30, 2020 | Updated: Oct 14, 2020

This page is "secure" which means that it was sent to you using HTTPS, which, in turn, means that it was encrypted in-flight between my web server and your computer. Fine. But what does that say about the data someone enters on this page?


The fact that a web page was downloaded to you securely (HTTPS) implies nothing about how data entered on that page is uploaded. Don't believe me? I don't blame you. But, it's true. And yes, this means you have been lied to for years about secure web pages/sites. Many many years. The forms below illustrate my point.

The HTTPS Submit button below works as expected, whatever data you type is uploaded using HTTPS and you end up at a secure web page on this site. Boring.

What day of the week is it?

However, the HTTP submit button below uploads the data you enter to a non-existing page on my JavaTester.org website. You get a 404 error because the web page does not exist. That is irrelevant to the issue at hand. YOU SHOULD GET AN ERROR (or warning) THAT DATA IS BEING SUBMITTED INSECURELY VIA HTTP. Most browsers (test results are below) fail to warn the user. (I would have sent the data to a valid HTTP web page, but I don't have one. All my websites use nothing but HTTPS.)

What day of the month is it?


Here is the underlying HTML for these two forms. In the first one, the FORM ACTION specifies HTTPS, in the second one it uses HTTP.

< form action="https://michaelhorowitz.com/processform1.php" method="post">
What day of the week is it?
< input type="text" name="weekday" value="EnterWeekday">
< input type="submit" value="HTTPS Submit">
< / form>

- - - - - - - - - - - - - - - - - - - - - -

< form action="http://JavaTester.org/insecuretestpage.php" method="post">
What day of the month is it?
< input type="text" name="monthday" value="EnterDate">
< input type="submit" value="HTTP Submit">
< / form>

- - - - - - - - - - - - - - - - - - - - - -

I find this quite ironic. When it comes to data being sent from a web server computer to you, the browsers are quite strict, but in the other direction, the direction where passwords travel ... not so much.

To illustrate the strict security of incoming/downloaded data, realize that although a web page may appear to be a single thing, under the covers it is composed of many individual components. The most obvious components are the images. Each image is fetched individually. For a web page to be considered "secure" by a web browser, all the images need to have been retrieved using HTTPS. If one of them was, instead, included using HTTP, then the page is considered Mixed Mode (or mixed content) and many browsers will issue a warning.

I created a sample web page that does exactly this (see mixedmode.php) so you can see the warnings, if any, from your web browser. There are warnings about insecurely retrieving images, but none about insecurely transmitting a password. Go figure.


Good Web Browsers

Windows 10: Firefox version 73 (current as of Feb. 2020) warns: "The information you have entered on this page will be sent over an insecure connection and could be read by a third party. Are you sure you want to send this information?"

Firefox 73 on Windows 10
Firefox 73 on Windows 10

Android 10: Firefox (version 68.5.0) and Firefox Focus (version 8.0.26) warn with the same text, but different colors. The warning is exactly the same as Firefox on Windows.

Firefox and Firefox Focus on Android 10
Firefox and Firefox Focus on Android 10

iOS 13.3.1: Safari warns "This form is not secure. Are you sure you want to submit it?" This was tested in February 2020 with the then-current version, but I could not figure out, specifically, which version of Safari it was.

Safari on iOS 13
Safari on iOS 13

I am told by a trustworthy source that Safari on macOS does warn about this. I don't have exact details on versions of Safari or macOS.

Bad Web Browsers

Sample Page Not Found Error
If the insecure submission is allowed, you will see this error

The following web browsers fail to warn about the insecure data transmission and instead go directly to the non-existing page. They result in the Page Not Found error shown above.

  1. Windows 10: Chrome version 80 (tested Feb. 2020) through 87 (tested Dec. 2020)
  2. Windows 10: Brave version 1.3.118 (current as of Feb. 2020)
  3. Windows 10: Edge version 42.17134.1098.0 (the legacy version of the browser)
  4. Windows 10: Edge version 80.0.361.57 (new version based on Chromium)
  5. iOS 13.3: Firefox version 22.0 (current as of Feb 2020)
  6. iOS 13.3: Brave version 1.14.3 (current as of Feb 2020)
  7. iOS 13.3: DuckDuckGo version 7.38.0 (current as of Feb 2020)
  8. ChromeOS: Chrome version 79.0.3945.119 (current as of Feb 2020)
  9. Android 10: Chrome version 80.0.3987 (current as of Feb 2020)
  10. Android 10: Brave version 1.5.6 (current as of Feb 2020)
  11. Android 10: DuckDuckGo version 5.43.0 (current as of Feb 2020)

Google has struggled like heck to close this security flaw on desktop OSs.


Address Bar to the rescue?

To be fair, some web browsers are not ALL bad. Take, for example, Chrome 80 on Windows. While it does not issue an obvious in-your-face warning, it does detect the possible insecure data transmission and it makes a small change to the address bar. Below we see three different indicators Chrome uses.

On the top, it is displaying the fully secure page, my blog about hovering the mouse over a link. Don't you miss green for indicating a good state? On the bottom it is viewing my Mixed Mode tester page which it detects as obviously not secure. This page is in the middle and I am pretty sure that no one will have any clue what the "i" in a circle means. If you click it, Chrome says "Your connection to this site is not fully secure." Useless words that convey no information.

Chrome 80 address bar flags
Chrome 80 address bar flags on Windows

On Android 9, however, Chrome is not so indicating. As the screen shots below indicate, both the Mixed Mode page and this page display exactly the same in the address bar.

Chrome on Android 9
Chrome address bars in Android 9

And, anyone who uses multiple browsers and/or multiple operating systems will never be able to track the meaning of the assorted icons used by different browsers.


I first wrote about this back in January 2006 How Secure Is That Web Page In The Window?. Back then, Firefox version 3 had an option about this, you could be warned, or not, about submitting information that was not encrypted. Firefox version 4 made it harder to control this. Interestingly, the warning from Firefox back then is exactly the same warning that it issues today.

That blog was prompted by an episode of the Security Now podcast with Steve Gibson from late in 2005. Interestingly, even after that podcast, Gibson's own personal website (grc.com) suffered from this problem. The site was all HTTPS but, on at least one page, it used HTTP to submit data.

Leo Notenboom also wrote about this, back in July of 2008: How Can an Https Website Still Not Be Secure?. He revised the article on March 18, 2020.

Internet Explorer, now part of history, gets mixed reviews. In February 2020, I tested IE 11 running on Windows 7.

The good news is that IE issues a warning (shown below) when HTTP is used to send data from an HTTPS page.

IE 11 warns about sending insecure data
IE 11 warns about sending insecure data

Bad news awaits however. If you click the More Info button, you end up with the following Question and Answer which is full of lies.

IE 11 lies
IE 11 lies, lies and lies again

Updated Oct 14, 2020. The insecure data submission now goes to my old JavaTester.org site. In early 2020, I gave up my FlashTester.org site which was used originally. Also added that Chrome version 87 is supposed to finally warn about this.



 @defensivecomput TOP Home => Submitting Data   
 michael--at--michaelhorowitz.com   Last Updated: December 30, 2020 5PM UTC  
  License Plate
Copyright 2001-2024
Copyright 2001-2024  
Printed at:   June 15, 2024 7:49pm   ET
Viewed 31,325 times since February 8, 2020 (20/day over 1,589 days)