Cookie Trust Without Integrity Check

This is CWE-565, a cookie-specific instance of the broader problem of trusting client-controlled state: the server reads a role, an identity claim, or session-relevant state directly out of a cookie and makes a security decision based on it, without a cryptographic signature or HMAC to detect tampering. The distinguishing feature versus the broader external-control-of-critical-state category is the fix that actually closes the gap: it isn't necessarily about moving the data server-side entirely, sometimes a cookie genuinely is a reasonable place to store session-relevant state, it's specifically about adding integrity protection so the server can tell a legitimate cookie from a hand-edited one. A signed cookie (one where the value includes a MAC computed with a server-only secret) fails closed the moment it's tampered with, since any edit invalidates the signature; an unsigned cookie holding the same value has no way to detect the difference.

• Session or identity cookies that store a role, permission level, or account identifier directly in a readable, unsigned value
• "Remember me" or persistent-login cookies that encode user identity without a corresponding integrity check
• Feature-flag or plan-tier cookies that gate paid functionality based on a client-readable value

• Decode a cookie's value (base64, JSON, or plain text) and check whether it contains an identifiable role, permission, or identity claim with no accompanying signature or MAC
• Modify the decoded value and re-encode it, replacing it in the request, and observe whether the server accepts the tampered cookie and behaves according to the modified value

• A cookie value with its role or identity field changed (role=user modified to role=admin) and re-encoded in whatever format the original cookie used
• Repeating the same modified value across multiple requests to test for consistent acceptance rather than a one-off anomaly

For every cookie set by the target, decode its value and inspect whether it contains a role, identity, or permission-relevant claim with no accompanying signature suffix or separate integrity token. Where such a cookie is found, modify the relevant field, re-encode it in the original format, and replay it to see whether the server accepts the change and adjusts its behavior accordingly, which confirms the value is trusted without verification.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• A cookie that looks like it holds sensitive state but is actually just an opaque session identifier, with the real state kept server-side and looked up by that identifier, is not vulnerable even though the cookie's value can be freely modified, since a modified, unrecognized session ID simply fails to match any real session.
• Confirm the cookie's content is directly interpreted as the security-relevant state itself, not just a lookup key, before treating it as a finding.

Manual Testing Methodology

Here is a systematic approach to identifying Cookie Trust Without Integrity Check vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Cookie Trust Without Integrity Check specifically, capture a valid pre-authentication session identifier, force it onto a victim session (via a link or shared cookie path), then authenticate as the victim and check whether the pre-set identifier remains valid post-login; separately, attempt to tamper with cookie/session-token content and see if the modified value is still accepted.

Compare the response against your baseline, looking specifically for a session identifier that survives login unchanged (fixation confirmed), or a tampered cookie/token value that the server still treats as valid — either indicates the session isn't properly regenerated or integrity-checked.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Cookie Trust Without Integrity Check, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Session-management flaws let an attacker take over an authenticated session without ever obtaining the victim's actual credentials. Session fixation lets an attacker set a known session identifier on a victim before login and then use that same identifier once the victim authenticates, inheriting their session outright. A session cookie that isn't integrity-protected can be tampered with directly, letting an attacker forge or elevate a session's claimed identity or privileges.

Both failure modes are attractive to attackers precisely because they skip the credential-theft step entirely — no phishing, no password guessing, just a manipulated identifier or cookie value.

The practical result in either case is full account takeover for the affected session, with the same downstream impact as if the attacker had stolen the password directly.

Prevention and Secure Coding

Preventing Cookie Trust Without Integrity Check takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Regenerate the session ID on authentication. Issue a brand-new session identifier immediately after login, invalidating whatever pre-authentication session existed — this defeats fixation regardless of how the attacker obtained the original ID.

Sign or store sessions server-side. Use a signed session token (verified with a server-held secret) or a server-side session store, so a client can't forge or modify session content undetected.

Cookie security flags. Set HttpOnly, Secure, and an appropriate SameSite value on session cookies as a baseline, regardless of the other controls in place.

Expire sessions actively. Enforce both inactivity timeout and explicit invalidation on logout server-side — a client-side "logged out" state that leaves the server-side session valid doesn't actually end the session.