When two browsers inherited one cart

Boundary

Browser to anonymous session

Observed effect

Shared cart state

Engineering focus

Session authority precedence

One browser's edit appeared in the other

The two browser contexts started separately. Both were controlled for the research, both were anonymous, and each should have kept its own cart. Then an edit made in one appeared in the other.

A login isn't what makes a cart private to a session. The application already remembers an unsigned-in browser's choices as it moves between pages. That remembered state still needs an owner, even when the owner is an anonymous session rather than an account.

The notes traced the crossover to a precedence decision: client-provided navigation state took priority over a server-issued session that was already present. The contexts then shared cart state. Changes persisted and appeared in the other context, which ruled out the narrower explanation of one misleading page render.

This was an anonymous-session finding. The notes do not show guessed identifiers, access to an unknown user's session, or account takeover. They also establish no checkout, payment, order, or customer identity disclosure. The shared cart was the result, not evidence for everything that might sit beyond it.

GET /redacted/cart HTTP/1.1
Host: research.example
Cookie: session=[REDACTED]
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, no-store
Content-Length: 72

{"cart":"[REDACTED]","items":[{"marker":"synthetic-item","quantity":1}]}

The input that chose the session

Navigation state and session identity have different jobs. One helps the browser continue a journey. The other decides whose stored data the server will use. In this case, a value meant for the first job was allowed to do the second.

Longer, less predictable session identifiers wouldn't settle that problem. No credential guessing was established. The server accepted a competing source of identity despite already having a session.

The implementation review would start where the application chooses its effective session. Which inputs can affect that choice? Which one wins when they disagree? The notes establish the wrong result, but they don't reveal the middleware order or storage model behind it.

Give navigation a narrower job

The proposed repair makes the choice explicit. A validated, server-issued cookie identifies the anonymous session. Navigation data cannot replace it. If there is no valid cookie, create a fresh session instead of adopting an identity supplied by the client.

A product may still need a link that resumes a workflow. Give that link a separate token with a narrow purpose, an expiry, and one permitted use. Continuing a cart operation should not grant all the authority of a different browser's session.

Decide who can redeem the token, too. It may need to be tied to the current session or an independently verified recipient. A valid signature says the token was issued intact; it doesn't say that the browser holding it is entitled to use it.

This illustrative sketch is proposed server logic, not code from the assessed application.

session = validate_server_issued_cookie(request)
if session is absent:
    session = create_fresh_anonymous_session()

if intended_workflow_is_requested:
    grant = validate_purpose_and_expiry(workflow_token)
    require grant.permits(current_context, intended_action)
    atomically:
        consume_once(grant)
        apply_permitted_workflow(session, grant)

persist_cookie_for(session)

Consuming the grant and applying its operation should commit together. Otherwise, a failure could leave a usable token after the change has succeeded, or spend the token without completing the change.

Keep the boundary through sign-in

Keep the usual cookie protections. HttpOnly limits script access, and Secure limits transmission to secure connections. Neither can correct a server that lets navigation data choose the session.

Use deliberate cookie scope, handle competing cookie variants, and reject invalid session references. Log the reason for a session change without logging reusable credentials. That gives maintainers a useful record without creating another copy of a session secret.

Sign-in deserves a separate review. Rotate the identifier when an anonymous session becomes authenticated, invalidate the old one, and apply an explicit policy for any cart migration. Moving selected items forward must not accidentally preserve the old session's authority or merge another browser's state.

This is preventive guidance, not another observed failure. The recorded test stopped at anonymous carts.

Test the carts, not just the cookies

Use synthetic sessions and an isolated application test harness for these checks. Assert the effective server-side session and cart contents as well as the cookie response.

The question for a retest

Do the carts stay separate through normal navigation, legitimate continuation flows, and sign-in? A retest needs to answer that on a corrected build. A new cookie attribute alone would not address what happened here, and no completed retest is claimed in these notes.

For the code review, keep coming back to one question: which input gets to decide whose cart this is?