Is your site sending password hashes to the browser?

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?

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?

Which standards does it relate to?

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.

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 shows what it includes. Pulse or Deep explains what each scan reads, and the full list of checks shows the rest.