# Is your site sending password hashes to the browser?

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

This Deep scan check flags password hashes in public pages or API responses, usually from sending whole user records to the browser. Here is the fix.

This check flags password hashes in a page or API response anyone can read, in a known hash format. It usually means the server sends whole user records to the browser instead of the fields it needs.

## What does this check look at?

It looks at whether a public page or API response contains password hashes in a known hash format. Hashes are not the passwords, but anyone holding them can guess weak passwords offline with no limit on attempts. OWASP notes that strong passwords stored with modern hashing algorithms should be effectively impossible to crack, which leaves weak passwords exposed.

Only a Deep scan runs it, after you prove you own the site.

## What does a result mean?

| What the report shows | What it means | What to do |
| --- | --- | --- |
| High finding | Several distinct hashes appeared in a public response. | Stop sending them today, then reset affected passwords. |
| Medium finding | A single hash matched, which may be an example. | Check where it came from. |

Hashes are never kept or cracked, and a single match may be a documentation example. 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 first when it is confirmed. Anyone could use a finding of this kind on their own, with no victim and no second step. Confidence starts high, because a response from your site shows the thing itself. 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 | Anyone who loads the public response |
| The protection that should stop it | Which user fields the server sends to the browser |
| What is reached | Password hashes in a response read without signing in |
| What follows | Offline password guessing against the affected accounts |

## Which standards does it relate to?

| Standard | Reference |
| --- | --- |
| OWASP Top Ten | `A01:2025` Broken Access Control |
| CWE | `CWE-200` |
| CWE | `CWE-359` |

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

Return only the fields the browser needs, and test that no hash can appear again.

:::fix-prompt any
My site sends password hashes to the browser: [paste the route or page from the report]. Find where user records are loaded and sent to the client (page props, server component payloads or API responses). Select only the fields the client needs, never the whole user row, using an explicit select or serializer. Add a test that fails if any response contains a bcrypt, argon2, scrypt or PBKDF2 hash. Then tell me how to force password resets for the accounts that were exposed.
:::

## How to check

Say Atlas, our example app at `atlas.example`, returns the full user row from its team members route. A Deep scan sees several hashes in that response and flags it without keeping any.

Deep scans come with the Deep plan, and [pricing](/pricing) shows what it includes. [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

### If passwords are hashed, why is this serious?

Because hashes can be guessed offline. Anyone with the hash can try common passwords as fast as their hardware allows, with no lockout.

### Did Lockpick keep or crack the hashes?

No. It matches the hash format and keeps neither the values nor the accounts they belong to.

## Sources

- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07
- [Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html), OWASP Cheat Sheet Series, read on 2026-10-07