Safeguard
Application Security•

CWE-315 Cleartext Storage of Sensitive Information in a Cookie

Cookies live on the user's machine and travel with every request. Putting passwords or auth data in them in cleartext hands them to anyone with a browser tool.

Safeguard Security Team
3 min read

CWE-315 is the web-specific version of cleartext storage: the product stores sensitive information in cleartext in a cookie.

Any site that sets cookies is in scope. The cookie is stored by the browser, shown in developer tools, and sent back with requests, so it is one of the most exposed places to keep a secret.

How it happens

Developers sometimes use a cookie as a lightweight way to remember a user. "Remember me" gets implemented by saving the username and password in the cookie, or an admin flag, or a token that is the password itself.

MITRE notes attackers can use widely available tools to view the cookie and read the sensitive information. Encoding such as base64 does not help, since techniques exist to identify and reverse the encoding.

MITRE's observed examples:

  • CVE-2002-1800: an admin password in cleartext in a cookie.
  • CVE-2001-1537: a default configuration with cleartext usernames and passwords in a cookie.
  • CVE-2001-1536: usernames and passwords in cleartext in cookies.
  • CVE-2005-2160: authentication information stored in cleartext in a cookie.
# Vulnerable: credentials placed in a cookie
resp.set_cookie("auth", f"{username}:{password}")
# Better: random session ID, state kept on the server
session_id = secrets.token_urlsafe(32)
store_session(session_id, user_id)
resp.set_cookie("sid", session_id, httponly=True, secure=True, samesite="Lax")

What an attacker gains

The listed consequence is loss of confidentiality: reading application data. With a password or auth token in hand, the attacker can log in as the user.

How to find it

MITRE says static analysis (SAST) can find some instances by modeling data flow in source or compiled code. By hand, log in and open the browser's cookie viewer. Anything that looks like a name, a password, a role or a readable token needs a second look. Search code for set_cookie, setcookie and document.cookie writes and check what values go in.

How to fix it

The record lists no formal mitigations. Standard practice:

  1. Put only an unguessable session identifier in the cookie, and keep the real state on the server.
  2. If data must travel in the cookie, sign it, and encrypt anything sensitive.
  3. Set Secure and HttpOnly on the session cookie so it stays off plain HTTP and out of page scripts.
  4. Never store a password in a cookie. For "remember me," use a separate random token that can be revoked.

Quick check

Is base64 encoding a cookie value enough?

No. It is trivially reversible. Use a random identifier, or sign and encrypt the data.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.