# Could your login form leak passwords in the address or over HTTP?

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

The password form check reads how a form with a password field declares it will send data, and flags plain HTTP or passwords placed in the address.

The password form check reads how a form with a password field declares it will send data, and flags a plain http destination or a method that would put the password in the page address.

## What does this check look at?

It looks at whether a form with a password field declares a plain HTTP destination or a method that would put the password in the address. A password in an address ends up in browser history, server logs and analytics. Lockpick never sends attack payloads, fills in your forms or tries passwords.

Pulse and Deep scans both run it.

## What does a result mean?

| What the report shows | What it means | What to do |
| --- | --- | --- |
| Medium finding | The declared method or destination is unsafe for a password. | Use POST to an https address you control. |

Scripts may change how the form really sends, and no form is ever submitted. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.

## How serious is a finding?

Fix this soon. A finding of this kind needs a victim or a second step before it causes harm, so it ranks below anything someone could use directly. Confidence starts at medium, because it rests on a pattern in your content. The report lists what to fix by how directly someone could use it, not by the severity label.

### What does a confirmed finding have to show?

| Part | For this check |
| --- | --- |
| Where it starts | A visitor typing a password into the form |
| The protection that should stop it | The form sends it by GET, over HTTP or to another site |
| What is reached | Address bars, logs, the network or the other site |
| What follows | The password can be seen on its way |

## Which standards does it relate to?

| Standard | Reference |
| --- | --- |
| OWASP Top Ten | `A07:2025` Authentication Failures |
| CWE | `CWE-319` |
| ASVS | `v5.0.0-12.2.1` |

Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.

## Fix it with your AI

Check both the form markup and the script that really submits it.

:::fix-prompt any
Review every form on my site that has a password field (login, signup, reset, settings). Make sure each one submits with POST, never GET, to an https:// address on my own site or my auth provider, and that no JavaScript handler copies the password into a URL, query string, log or analytics event. Fix any that do and show me the changes.
:::

## How to check

Say Atlas, our example app at `atlas.example`, has an old login form with no method set, which browsers treat as GET. The check flags it because a password would land in the address.

Run a Pulse scan from your Lockpick account to see it for your site. [Pulse or Deep](/docs/get-started/pulse-or-deep) explains what each scan reads, and the [full list of checks](/checks) shows the rest.

## Questions people ask

### My form has no method attribute. Is that a problem?

It can be. Browsers default to GET, which puts field values in the address, unless a script stops the normal submit.

### Is this the same as the form destination check?

No. That one looks at every form for plain http. This one looks only at forms with a password field, and also at the method.

## Sources

- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07
- [What we never do](https://www.lockpick.app/docs/security/what-we-never-do), Lockpick docs, read on 2026-10-07