Is Storing a Recoverable Password in a Browser Cookie a Security Risk?

Yes, this is a serious vulnerability. Cookies can be exposed through browser vulnerabilities, malware, insecure handling, accidental disclosure, or network mistakes. A recoverable password gives an attacker the credentials themselves, which is worse than stealing a single session. Passwords should never be stored in a cookie or retained in recoverable form anywhere.

The server should receive the password over a properly protected HTTPS connection, then immediately verify it against a salted, slow one-way password hash. It should never store the plaintext password or an encrypted version that can be decrypted later. For “Remember Me,” generate a long, unpredictable random token, store only a hash or otherwise protected record of that token on the server, and put the token in a cookie marked Secure, HttpOnly, and with an appropriate SameSite policy. Tokens should be revocable, rotated after use or login, expire, and be invalidated when the user signs out or changes their password.

This should be documented as a finding with evidence handled carefully, since the exposed value may be an actual credential. Avoid testing it beyond what your authorization allows, redact it in reports, and recommend immediate remediation, credential rotation, token invalidation, and a review of whether the same password was reused elsewhere.

A remember-me cookie can legitimately keep someone signed in, but it should contain only a random bearer token—not a password. Anyone who obtains that token may be able to impersonate the user until it expires or is revoked, so the feature should have a limited lifetime and should not silently bypass important security controls such as step-up authentication for sensitive actions.