Cookie tests
Everything on this page is set, read, and cleared by JavaScript on the client. No server round-trip. Behind the scenes, Firebase Hosting's CDN strips every cookie name other than __session before requests reach our backend — so a server-side cookie test would only confirm the CDN's stripping behavior, not the cookie itself. Doing it from JS is honest about what's actually being tested.
Current cookies (visible to JavaScript)
HttpOnly cookies are intentionally invisible here — that's the point of HttpOnly. They're still stored by the browser; document.cookie just can't read them. Submit a login at /login/post-form to see one: the server sets __session as HttpOnly (and a JS-readable counterpart bb_session_js with the same value, for visibility).
Set cookies (client-side)
- plain
- plain
- · · samesite
HttpOnly demo
You cannot set an HttpOnly cookie from JavaScript — that is the point of the flag. To see one:
- Submit any synthetic credentials at /login/post-form. The login sink sets
__sessionasHttpOnly; Secure; SameSite=Lax. - Come back here. You'll see
bb_session_jsappears in the list above (same value, no HttpOnly) but__sessiondoes not — becausedocument.cookiecannot read HttpOnly cookies even though the browser is storing them.
Clear cookies
HttpOnly cookies (like __session) can't be cleared from JS. Clear them via your browser's site-data settings, or close the tab — the login sink issues them as session cookies.
What this measures
For any intermediary sitting between the browser and a server, the question is: does it respect cookies? Set a few here, then visit /fingerprint/data — Firebase Hosting will only forward __session to the server, so the only useful cross-check is the JS-readable cookie list above.