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:
- Put only an unguessable session identifier in the cookie, and keep the real state on the server.
- If data must travel in the cookie, sign it, and encrypt anything sensitive.
- Set
SecureandHttpOnlyon the session cookie so it stays off plain HTTP and out of page scripts. - 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.