A login form submits, a Set-Cookie header comes back, and DevTools shows something like session=eyJ1c2VySWQiOjEwNDIsInJvbGUiOiJhZG1pbiJ9. It looks encoded. It is not encrypted. Base64-decode it and you get {"userId":1042,"role":"admin"} sitting in plaintext in every request header, every proxy log, every browser history entry, and every XSS payload's reach. This is CWE-315, Cleartext Storage of Sensitive Information in a Cookie, and it is one of the most persistent, least glamorous vulnerabilities in web application security. It rarely makes headlines on its own, but it shows up as a contributing factor in account takeover chains, IDOR exploitation, and session hijacking across audits every quarter. This post explains what the weakness actually is, how attackers exploit it, why it keeps recurring in 2026 codebases, and how Safeguard helps engineering teams find and eliminate it before it ships.
What Is CWE-315, and Why Does It Still Slip Through Review?
CWE-315 is the specific case of CWE-312 (Cleartext Storage of Sensitive Information) where the storage location is a cookie sent to the client's browser. It slips through review because cookies feel transient and client-side, so developers treat them as low-stakes state rather than as data leaving the trust boundary. A cookie is not a private variable — it is written to disk in the browser's cookie jar, replayed on every matching request, cached by intermediate proxies, and visible in plaintext to anyone with browser DevTools, a corporate SSL-inspecting proxy, or access to a shared machine. Encoding schemes like Base64, URL-encoding, or JSON serialization are frequently mistaken for encryption during code review, because the value looks "obfuscated" at a glance. It isn't. Base64 is a two-second decode in any terminal, and most static analysis tools flag hardcoded secrets far more readily than they flag "this cookie value is reversible."
What Kind of Data Actually Ends Up in Plaintext Cookies?
In practice, it is almost always identity and authorization data: user IDs, email addresses, role flags, tenant IDs, and sometimes full session objects. A typical vulnerable pattern looks like prefs={"uid":88213,"tier":"enterprise","isAdmin":false} set as a non-HttpOnly, non-encrypted cookie for "convenience" — so the frontend can read it without an extra API call. Some legacy .NET and PHP applications from the 2000s and 2010s went further, storing username and a weak hash of the password directly in a "remember me" cookie, a pattern OWASP's Testing Guide (WSTG-SESS-02, "Testing for Cookies Attributes") has flagged for over a decade. Even modern JWT-based cookies can fall into this trap: a JWT's payload is signed, not encrypted, so anything placed in the claims — PII, internal role names, feature flags — is fully readable by decoding the middle segment, regardless of signature validity.
How Do Attackers Turn a Readable Cookie Into Account Takeover?
The exploit path is direct: read the cookie, modify the field that matters, replay it. If a cookie carries role=user, an attacker with local access, a malicious browser extension, or an XSS foothold can rewrite it to role=admin and reload the page — this is a textbook privilege escalation via client-side trust, distinct from but often chained with CWE-565 (Reliance on Cookies without Validation). If the cookie carries a raw userId, incrementing it becomes an IDOR attack surface, letting one authenticated user page through other accounts' data by editing a single digit. Cleartext cookies are also a favorite target in session-fixation and shared-computer scenarios: on public or corporate machines, exported browser profiles and disk-level cookie stores hand over the plaintext value to anyone with subsequent file access, no active interception required. None of this needs sophisticated tooling — a browser's built-in cookie editor and five minutes are enough.
Why Do Compression and Caching Make This Even Riskier?
Because compression can turn a readable cookie into a side-channel that leaks other secrets on the same connection. The CRIME attack, disclosed by Juliano Rizzo and Thai Duong at Ekoparty in September 2012, showed that TLS-level compression could be used to extract cookie values byte-by-byte by observing compressed response sizes. The BREACH attack, presented at Black Hat USA in August 2013, extended the same oracle technique to HTTP-level (gzip) compression of response bodies that reflect cookie or token values. Both attacks specifically target session cookies and CSRF tokens sitting in predictable positions in responses. The lesson compounds the original weakness: cleartext, unencrypted cookie content isn't just readable by anyone who obtains the cookie — under the right conditions, it can be extracted remotely without ever obtaining it directly, purely by measuring how compression behaves around it.
What Do Compliance Frameworks Actually Require Here?
Every major framework that touches Safeguard's customer base — PCI DSS, GDPR, and SOC 2 — treats cleartext exposure of sensitive data as a control failure, not a style preference. PCI DSS Requirement 3 (rendering stored account data unreadable) applies directly if payment-adjacent identifiers ever land in a cookie, and PCI DSS 4.0, which became fully enforceable in March 2025, sharpened expectations around where sensitive authentication data can legally persist. GDPR Article 32 requires "appropriate technical measures," and regulators have repeatedly pointed to encryption-in-transit-and-at-rest as the baseline example of what "appropriate" means for identifying data — a plaintext cookie holding an email address or user ID is squarely in scope. SOC 2's Confidentiality and Processing Integrity criteria expect organizations to demonstrate that sensitive data isn't exposed to unauthorized parties by design, and auditors increasingly ask for evidence of session and cookie handling reviews as part of the CC6 control family. A single cleartext cookie finding, multiplied across dozens of services, is exactly the kind of recurring minor exception that erodes an audit.
How Do You Actually Fix and Prevent This at Scale?
The fix is straightforward per-instance and hard to guarantee at scale, which is the real problem. Per-cookie, the remediation is: store only an opaque, high-entropy session identifier in the cookie, keep the actual user data server-side in a session store, and set HttpOnly, Secure, and SameSite=Strict or Lax on every session cookie (Chrome made SameSite=Lax the default for cookies without an explicit attribute starting with Chrome 80 in February 2020, but that default doesn't stop developers from overriding it insecurely). If client-visible state is genuinely required, encrypt it with authenticated encryption (AES-GCM, not Base64) using a server-held key, and keep the payload under the ~4096-byte per-cookie limit that most browsers enforce. The hard part at scale is that this discipline has to hold across every service, every framework default, and every engineer who reaches for "just stick it in a cookie" as the fast path — which is exactly the pattern that survives code review because it works in the demo and looks encoded enough to pass a skim.
How Safeguard Helps
Safeguard treats cleartext-cookie exposure as a supply-chain-scale detection problem, not a one-repo lint rule. Our scanning pipeline inspects Set-Cookie headers and client-side storage calls across your services to flag cookies carrying identifiers, roles, tokens, or PII in unencrypted or trivially-decodable form (Base64, plain JSON, unencrypted JWT claims), mapping each finding to CWE-315 and the relevant CWE-312 family so it's audit-ready evidence, not just a warning. Because Safeguard sits across your full build and deployment pipeline, it catches this pattern not only in first-party code but in the third-party and open-source components you depend on — where a vulnerable auth library or SDK can quietly reintroduce cleartext cookie handling into an otherwise clean codebase. Findings are prioritized by exploitability (is the cookie missing HttpOnly? is it reachable from an XSS-vulnerable page? does it carry authorization data rather than just preferences?) so security and engineering teams fix the ones that matter for account takeover risk first. And because SOC 2 and PCI auditors ask for this exact control evidence, Safeguard's reports give compliance teams a direct, reusable answer instead of a scramble every audit cycle.