Vulnerability Overview
Sensitive data — including the flag — was stored directly in a client-side cookie, encoded in Base64. Base64 is a data encoding scheme, not an encryption algorithm. It is trivially reversible by any user who inspects their own browser cookies.
Discovery
After submitting any login attempt, a new cookie appeared in the browser's Application tab:
Name: secret_recipe
Value: cGljb0NURntjMDBrMWVfbTBuc3Rlcl9sMHZlc19jMDBraWVzX0M0MzBBRTIwfQ%3D%3DThe URL-encoded %3D%3D at the end decodes to ==, which is characteristic Base64 padding. Decoding the full value immediately yielded the flag.
Root Cause
The developer stored the flag in a cookie under the assumption that Base64 encoding provided some form of security. It does not. Base64 is designed for data transport, not confidentiality — it has no key and is fully reversible by anyone with access to the encoded string.
| Control | Implementation |
|---|---|
| Never store sensitive data client-side | Cookies, localStorage, and sessionStorage are all attacker-readable |
| Use server-side sessions | Store only an opaque session ID in the cookie; keep all sensitive data on the server |
| Understand encoding vs encryption | Base64, hex, URL encoding, and ROT13 are all reversible without a key — they are not encryption |
Key Insight: Cookies are client-side storage. Every value in them is visible to the user and to anyone with physical or network access to the device. The only safe content for a cookie is an opaque, unpredictable session identifier that references server-side state — never the state itself.