Skip to main content

Cookie Monster Secret Recipe picoCTF 2025 Solution

The session cookie is a URL-encoded Base64 blob, so peel off both layers and the flag is sitting in plaintext inside it.

Published: April 2, 2025Updated: August 25, 2026

Description

Cookie Monster's login page sets a secret_recipe cookie that already contains the flag. Harvest the cookie and decode it from Base64.

Web

Submit username=test, password=test (or any pair). The page accepts and sets cookies regardless, which proves auth isn't enforced.

Open DevTools and copy the secret_recipe cookie value (Chrome/Edge: Application > Cookies; Firefox: Storage > Cookies; Safari: Develop > Web Inspector > Storage).

URL-decoding gotcha: cookie values in DevTools are URL-encoded (%20, %3D). URL-decode before Base64-decoding. One-liner: python3 -c 'import urllib.parse; print(urllib.parse.unquote(...))'.

bash
curl -i http://verbal-sleep.picoctf.net:<PORT_FROM_INSTANCE>/ -d 'username=a&password=a' | grep -i set-cookie

Solution

Want to try it yourself first?

The guided walkthrough reveals hints one step at a time.

Walk me through it
  1. Step 1Dump the cookie
    Observation
    The challenge names a secret_recipe cookie, and the login page sets cookies whatever credentials you give it. The flag is in a cookie value, not behind the login.
    Look for secret_recipe. Its value is Base64, often URL-encoded so the trailing == becomes %3D%3D. Substitute the %3D back to = (or feed through urllib.parse.unquote) before decoding.
    What didn't work first

    Tried: Looking in the Network tab request headers instead of the Application tab cookie storage.

    The Network tab does show the Cookie and Set-Cookie headers, but the values are buried in walls of header text and awkward to copy cleanly. The Application tab, or Storage in Firefox, lists each cookie as its own row with the name and raw value ready to copy.

    Tried: Pasting the cookie value straight into a Base64 decoder without removing the URL encoding first.

    With %3D still in place, a Base64 decoder hits an invalid character and either errors out or truncates. That sequence is a URL-encoded equals sign, the padding Base64 puts at the end. URL-decode first, turning %3D back into = and %2B into +.

    Learn more

    HTTP cookies are key-value pairs set by the server via a Set-Cookie response header and automatically sent by the browser in subsequent requests to the same origin. Cookies are visible to anyone who can inspect network traffic or browser developer tools - they are not secret by default. Sensitive information should never be stored directly in a cookie unless it is encrypted and signed.

    URL encoding (also called percent-encoding) is used in cookies because some characters like =, +, and / have special meaning in HTTP headers and URLs. The %3D sequence represents the equals sign =, which is the Base64 padding character. A browser or curl will decode percent-encoding automatically; command-line tools like echo need you to substitute %3D with = first (or use python3 -c "import urllib.parse; print(urllib.parse.unquote(...))").

    In the browser's DevTools Application tab (Chrome/Edge) or Storage inspector (Firefox), you can see all cookies for the current domain, their values, expiry, security flags (HttpOnly, Secure, SameSite), and domain scope. This is the fastest way to inspect cookie values during web security challenges or reconnaissance. The Cookie and JWT CTF guide covers signed-cookie tampering, JWT alg=none, and other cookie attacks beyond plain decoding.

  2. Step 2Decode the blob
    Observation
    The cookie is alphanumeric with %3D on the end, which is a URL-encoded equals sign. That is Base64 padding, so URL-decode first, then Base64-decode.
    Either paste into CyberChef or pipe through base64 -d to reveal picoCTF{...}.
    What didn't work first

    Tried: Trying to decode the value directly in the terminal with echo 'value' | base64 -d before URL-decoding, resulting in garbled output or an error.

    echo passes the percent-encoded string through literally, and base64 chokes on the % characters, which are not in its alphabet. URL-decode first, with urllib.parse.unquote or by swapping the sequences back by hand.

    Tried: Assuming the decoded output needs further decoding because it looks like random text at first glance.

    Decoded Base64 can carry slashes, plus signs, and capitals that look scrambled at a glance. If the result starts with picoCTF{ you are done. Decoding a second time just produces garbage.

    Learn more

    Storing data as Base64 in a cookie is a pattern seen in many web frameworks for session management and state passing. Flask's default session cookie, for example, stores a Base64-encoded JSON object signed with a secret key. Without the signature, reading the cookie requires only decoding - it is not encrypted. This challenge demonstrates an even simpler case: no signing at all, just raw Base64.

    When performing web application security assessments, inspecting every cookie for Base64-encoded content is a standard early step. Tools like Burp Suite automatically detect and decode Base64 in requests and responses. The Burp Suite for picoCTF guide covers the Decoder shortcut and the Repeater loop you would use to re-send a tampered cookie back to the server. CyberChef's "Magic" recipe can identify the encoding automatically and chain decoding operations.

    The secure alternative is to store only an opaque, cryptographically random session ID in the cookie, and keep all sensitive data server-side in a session store. Frameworks like Django, Rails, and Spring all do this by default. Putting sensitive data client-side requires authenticated encryption (like AES-GCM) to prevent reading and tampering. See CTF Encodings for a quick reference of how to spot Base64, URL-encoded, hex, and ROT13 values at a glance.

Interactive tools
  • Flask Session DecoderDecode Flask / itsdangerous session cookies. Splits payload, decompresses zlib, parses JSON, and verifies the HMAC signature when given the secret.
Alternate Solution

Once you copy the cookie value, decode it instantly with the Base64 Decoder and then the URL Encoder / Decoder on this site - both tools run in the browser with no install required. Decode the percent-encoding first (to restore any %3D padding), then Base64-decode the result.

Flag

Reveal flag

picoCTF{...}

No login bypass is necessary; the secret is literally in the cookie jar.

Key takeaway

Cookies go to the browser and sit there in the open, and Base64 adds nothing, being reversible and keyless. An application that stores sensitive data in a cookie, rather than a server-side session behind an opaque token, hands it to anyone with DevTools or a proxy. The same mistake shows up whenever localStorage, URL parameters, or hidden form fields get treated as a security boundary.

How to prevent this

Base64 is encoding, not encryption. Treat anything sent to the client as readable.

  • Never put secrets, internal IDs, or user state directly in a cookie. Store only an opaque random session ID; keep the actual data server-side in a session store (Redis, database, signed JWT with a server-only key).
  • If client-side state is unavoidable, sign it (HMAC) so tampering is detected, and encrypt it (AES-GCM) so reading is blocked. Most frameworks (Django, Rails, Express cookie-session) ship this out of the box.
  • Set HttpOnly, Secure, and SameSite=Lax (or Strict) on every auth cookie so JS can't read it and CSRF attacks are blunted.

Related reading

Tools used in this challenge

Where to go next