Authentication · Verified identity
Cookie, Bearer and BFF: browser token architecture
Evaluate XSS, CSRF and session transport trade-offs.
Understand the concept
Cookies are attached by the browser according to scope and policy. HttpOnly limits script reading, Secure requires secure transport, and SameSite influences cross-site sending. None of these alone eliminates XSS or CSRF. Malicious script can still initiate actions as the user even when it cannot read a cookie.
An application commonly adds a Bearer header itself. Possession permits use, so constrain lifetime, audience and scope. localStorage exposes tokens to scripts; in-memory storage does not make XSS harmless and complicates reloads. URL tokens can leak through URL handling. Browser CORS rules do not replace credential validation.
A BFF can keep downstream tokens server-side and expose a session cookie to the browser. It still needs CSRF protection, session controls and constrained proxying. Choose an architecture based on actual clients, origins, rendering and identity-provider requirements rather than a universal recipe.
When designing the session boundary between Next.js and an API.
Claiming XSS is harmless with HttpOnly or that localStorage is always appropriate.
One topic. Three levels of depth.
Set-Cookie: session=<opaque>; Secure; HttpOnly; SameSite=Lax; Path=/Illustrative flags; assess cross-site needs and CSRF separately.
This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.
Try it yourself first.
An HttpOnly-cookie page has XSS. Can actions still be made as the user?
Show the solution and explanation
Yes: script can initiate authenticated same-origin requests.Yes. Reading a cookie and initiating a request carrying it are different.