Q256: Secure Cookies SameSite and Session Boundaries

What Interviewers Want To Evaluate

Interviewers want to know whether you can explain cookies as browser-managed HTTP state, not simply as small key-value storage.

They also want to know whether you understand session boundaries, token safety, cross-site behavior, CSRF risk, and why cookie attributes matter in real products.

This is a frequent senior topic because authentication bugs often hide in the gap between frontend assumptions and browser cookie rules.

Short Interview Answer

Cookies are browser-managed pieces of state sent with matching HTTP requests. Secure session cookies should usually use HttpOnly, Secure, appropriate SameSite, tight Path and Domain scope, and sensible expiration. HttpOnly reduces token theft through XSS, Secure restricts HTTPS transport, and SameSite controls cross-site sending behavior. I treat cookies as part of the browser security boundary and pair them with server-side authorization, CSRF protection where needed, session rotation, and clear logout behavior.

Detailed Interview Answer

Cookies are old, but they are still central to modern web authentication.

A cookie is set by a server response:

Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax; Path=/

The browser stores it and sends it on later matching requests.

That means cookies are not only frontend storage.

They are also network behavior.

Cookie Matching

The browser decides whether to send a cookie based on:

domain
path
scheme
expiration
SameSite policy
request context

Frontend code does not manually attach HttpOnly cookies.

The browser attaches them automatically when the request qualifies.

This is why fetch options and server cookie attributes must agree.

Important Attributes

Important cookie attributes:

HttpOnly
Secure
SameSite
Domain
Path
Expires
Max-Age
Priority
Partitioned

Each attribute changes risk.

Missing one can turn a reasonable session design into a production vulnerability.

HttpOnly

HttpOnly prevents JavaScript from reading the cookie through document.cookie.

That matters because XSS is dangerous.

If an attacker can run JavaScript, they may still perform actions as the user, but HttpOnly makes direct token theft harder.

Use HttpOnly for high-value session tokens.

Secure

Secure means the cookie is only sent over HTTPS.

For authentication cookies, this should be normal.

Without it, cookies can be exposed over insecure transport in mixed or downgraded environments.

Modern browsers also require Secure for some cross-site cookie behavior.

SameSite

SameSite controls when cookies are sent with cross-site requests.

Common values:

Strict
Lax
None

Strict is safest but can break normal flows where users arrive from another site.

Lax is a good default for many sessions because it allows top-level navigation while reducing cross-site request risk.

None allows cross-site sending and requires Secure.

Use None only when the product actually needs cross-site cookies, such as embedded widgets or separate app/API origins.

Domain and Path

Domain and path scope where a cookie is sent.

Prefer the narrowest scope that works.

Broad domain cookies can leak into unrelated subdomains.

Broad path cookies are sometimes fine for app sessions, but sensitive feature-specific cookies may deserve tighter paths.

Session Boundary

A session boundary answers:

which user is this?
which requests prove that identity?
when does the proof expire?
how can it be revoked?
what happens after logout?

Frontend UI state is not the session boundary.

The server is.

The UI can show authenticated navigation, but protected data and mutations must still be validated server-side.

Fetch Credentials

fetch controls whether browser credentials are included.

Examples:

fetch("/api/me", { credentials: "same-origin" })
fetch("https://api.example.com/me", { credentials: "include" })

For same-origin calls, defaults are often enough.

For cross-origin calls, credentials: "include" may be required.

The server must also return compatible CORS headers.

Logout

Logout is more than clearing React state.

It should include:

server-side session invalidation
cookie expiration
client cache cleanup
query cache cleanup
local progress or UI state decisions
redirect to safe page

If the server session remains valid, the user is not really logged out.

Common Mistakes

Common mistakes include:

storing session tokens in localStorage without threat modeling
missing HttpOnly on session cookies
using SameSite=None when Lax would work
forgetting Secure
using wildcard CORS with credentials
trusting client auth state
not invalidating server sessions on logout
over-scoping cookies to every subdomain

Interview Example

If asked, "Should we store JWTs in localStorage or cookies?"

A senior answer avoids a one-line rule.

Say:

"I would classify the threat model. For browser session auth, an HttpOnly, Secure, correctly scoped cookie often reduces token theft risk from XSS, but it introduces CSRF considerations. JavaScript-readable storage can be easier for APIs but increases token exposure if XSS occurs. The final design must pair storage with server authorization, CSRF controls, expiration, rotation, and logout."

Practice Prompt

Review a login response and identify:

Set-Cookie value
HttpOnly
Secure
SameSite
Domain
Path
expiration
CORS headers
logout behavior

Then explain whether the session boundary is clear.

Final Mental Model

Cookies are not just storage.

They are browser-managed request state.

Good cookie design makes identity explicit, scoped, revocable, and hard to steal accidentally.