Support Library

Forms and Passwords Sent over Plain HTTP

Whatever someone types into a form travels to the address in the form’s action. If that address, or the page itself, uses plain http://, passwords and personal details cross the network unencrypted, even when the page looks secure.

Author
CategoryWebsite Security
Length4 minute read
UpdatedNovember 1, 2026

The short answer

Serve every page that has a form over HTTPS, and make sure each form submits to an https:// address (or a relative path on the same HTTPS site). Check the action attribute on each <form> and any formaction on its buttons.

Where the data leaks

A form that submits over plain HTTP compared with one that submits over HTTPS Top: a sign-in form on an HTTPS page has action set to an http:// address. When the visitor submits, the email and password are sent unencrypted, so anyone on the network can read them. Bottom: the form posts to an https:// address, so the same data is encrypted all the way to the server. Form posts to http:// Sign-in form On an HTTPS page Visitor submits Email and password action="http://…" POST /login Sent unencrypted Readable on the network Passwords and personal data exposed Browsers warn before sending Form posts to https:// Sign-in form On an HTTPS page Visitor submits Email and password action="/login" Same HTTPS site Sent encrypted Only the server can read it Typed data stays private No browser warning A form that submits over plain HTTP compared with one that submits over HTTPS Top: a sign-in form on an HTTPS page has action set to an http:// address. When the visitor submits, the email and password are sent unencrypted, so anyone on the network can read them. Bottom: the form posts to an https:// address, so the same data is encrypted all the way to the server. Form posts to http:// Sign-in form On an HTTPS page Visitor submits Email and password action="http://…" POST /login Sent unencrypted Readable on the network Passwords and personal data exposed Browsers warn before sending Form posts to https:// Sign-in form On an HTTPS page Visitor submits Email and password action="/login" Same HTTPS site Sent encrypted Only the server can read it Typed data stays private No browser warning
A padlock on the page does not protect a form that submits somewhere else. The action address decides how the data travels.

How DNS Panopticon detects it

Security Posture reads your homepage HTML and looks at its forms. It resolves each form’s action, and any button’s formaction, against the page address. The results appear on the Website Application Security card.

FindingSeverityWhen it appears
Password form sent without encryptionHighThe homepage is served over plain HTTP and contains a password field.
Form submits over plain httpHighThe homepage is on HTTPS, but a form or submit button posts to an http:// address, and the page’s Content-Security-Policy does not include upgrade-insecure-requests (which would upgrade the submission).

Only the homepage is checked. Sign-in, contact, checkout and newsletter forms on other pages need the same review.

How to check it yourself

Right-click the form and choose Inspect, then look at the <form> tag’s action. When you submit a form that posts to http:// from an HTTPS page, Chrome and Firefox show a warning that the information will be sent over an insecure connection.

CommandWhat it shows
curl -s https://example.com | grep -oi '<form[^>]*>'Every opening form tag and its action (macOS, Linux, WSL).
curl -s https://example.com | grep -oi 'formaction="[^"]*"'Buttons that override the form’s action.
(Invoke-WebRequest -Uri https://example.com -UseBasicParsing).Content | Select-String -Pattern '<form[^>]*>' -AllMatches | ForEach-Object { $_.Matches.Value }The form tags, in Windows PowerShell.

Why it matters

  • Credentials. A password sent over HTTP can be captured on any shared network and then tried on other sites, since many people reuse passwords.
  • Personal data. Names, addresses and payment details sent unencrypted can breach privacy laws and card industry rules such as PCI DSS, which require strong encryption for cardholder data on public networks.
  • False reassurance. The padlock describes the page, not where the form sends data, so visitors cannot easily tell.
  • Browser warnings. Chrome marks pages with password fields on HTTP as “Not secure” and warns before an insecure form submission, which drives visitors away.

How to fix it

  1. Move the page to HTTPS and redirect its http:// address. See HTTPS and HTTP-to-HTTPS Redirects.
  2. Fix the action. Use a relative path such as action="/login", which inherits the page’s HTTPS, or a full https:// URL.
  3. Check third-party form services (newsletter, CRM, ticketing). Their embed code sometimes carries an old http:// endpoint; copy the current code from the provider.
  4. Make sure the endpoint itself accepts HTTPS. A form that posts to https:// on a server without a certificate simply fails.
  5. Add HSTS and upgrade-insecure-requests so browsers upgrade any remaining http:// submissions. See HSTS and Mixed Content.
BeforeAfter
<form action="http://example.com/login" method="post"><form action="/login" method="post">
<button formaction="http://forms.example.net/subscribe"><button formaction="https://forms.example.net/subscribe">

If the form posted to http:// and you now redirect that address, use a 308 redirect for the endpoint so the browser repeats the POST to HTTPS. A 301 may turn it into a GET and lose the form data. Better still, change the action so no redirect is needed.

FAQ

The page is HTTPS. Isn’t the form automatically secure?

No. The browser sends form data to the action address. If that address starts with http://, the data goes out unencrypted, whatever the page was loaded over.

Does a redirect from http:// to https:// on the endpoint fix it?

No. By the time the redirect comes back, the browser has already sent the data in the clear. Change the action itself.

What about forms that only collect an email address?

They still expose personal data and can be tampered with, so they should submit over HTTPS too. The password case is rated higher only because a stolen password unlocks an account.

Can I fix it without editing the HTML?

Adding upgrade-insecure-requests to your Content-Security-Policy makes modern browsers submit to https:// instead, and DNS Panopticon accepts that as a fix. Editing the action is still the cleaner solution.

Sources and further reading

Related support articles

HTTPS and HTTP-to-HTTPS RedirectsHSTS: HTTP Strict Transport SecurityMixed ContentEmail Phishing Protection: SPF, DKIM, DMARCHTTP Status Codes Explained