How nullcipher recognises it
In a Cookie: request header (raw HTTP, curl -H, a browser's "cookie" header copy) every cookie value is masked, because a request's cookie list is session state; so is every value in curl -b / --cookie name=value arguments. In a Set-Cookie: header only the first name=value pair's value is masked. Cookie names and the attributes Path, Domain, Expires, Max-Age, Secure, HttpOnly and SameSite stay readable. curl -b with a file name (no =) is left alone.
This is the rule text of the “Cookie value” detector in the masking engine, copied from the engine when this page was built. Detectors run in a fixed order and, where two overlap, the earlier one wins.
Example (fake)
curl shop.example.com/account -H 'Cookie: sessionid=EXAMPLE9f8e7d6c5b4a; theme=dark'
Set-Cookie: session=EXAMPLEnotreal123; Path=/; Secure; HttpOnly; SameSite=Lax
nullcipher replaces it with [COOKIE_1] and [COOKIE_2] and [COOKIE_3]. Both session values start with EXAMPLE. theme=dark is masked too, because nullcipher cannot know which cookie a site uses as its session; the names sessionid, theme and session and the attributes Path, Secure, HttpOnly and SameSite stay readable.
Why it matters in an AI chat
A session cookie is usually the whole login. RFC 6265 describes servers keeping a nonce, a session identifier, in a cookie and looking up the user's state with it. OWASP's Session Management Cheat Sheet puts it bluntly: once a session is established, the session ID is temporarily equivalent to the strongest authentication method the application used, password and second factor included. Whoever pastes it into a browser is logged in as you.
Which cookie holds the session is not written anywhere: it may be called sessionid, sid, connect.sid, _session, __Host-auth or anything a developer invented. That is why every value in a Cookie: request header is masked rather than guessed at, while the names stay, so the AI can still see which cookies were sent.
In a Set-Cookie: response header only the first name=value is the cookie. Path, Domain, Expires, Max-Age, Secure, HttpOnly and SameSite are its attributes, and they are exactly what an AI needs to check when a login does not stick or a cookie is not sent back, so they are left visible.
If it already leaked
- Log out of that session in the browser or app it came from. OWASP says a web application must invalidate the session at least on the server side when the user logs out, so on a well-built site the copied cookie stops working too. [2]
- If the site offers "sign out of all sessions" or "log out other devices", use it. Changing the password often has the same effect; OWASP recommends that the session ID is renewed after any privilege change, a password change included. [2]
- If you run the site, delete that session from your session store on the server. Deleting the cookie in a browser does nothing to a copy of it: the server looks up whatever session identifier it is handed. [1]
- Cookies that are not the session, such as analytics IDs (_ga) or preferences (theme, lang), grant no access. They can identify a browser, but there is nothing to revoke.
Sources
- RFC 6265: HTTP State Management Mechanism, section 8.4 Session Identifiers — checked 2026-09-23.
- Session Management Cheat Sheet — OWASP Cheat Sheet Series — checked 2026-09-23.
Open the full masking tool to mask a whole log, .env file or e-mail — every type at once — and restore the values in the AI's answer. Or see all 30 secret types and how to delete a chat you already sent.