Switching Staff Accounts Without Leaking the Last Person's Screen

On a shared office computer, staff often sign out and another person signs in within a minute. If a cached page, a stored response or a leftover in-page state survives the switch, the second person may briefly see the first person's customer data. This article proposes layered constraints and a rehearsal to check them. It is a conditional design. Adapt it to your stack, and do not read it as a claim that any setup is immune.

The artifact: account switch rehearsal

The rehearsal is a numbered script with an expected observation at each step. Each step checks one layer.

Layers to rehearse

Response caching. Pages and data responses that depend on the signed in person are marked so shared caches and the browser do not store them for reuse, or are keyed by a per account value. Decide per route, and write the choice in a table.
Client storage. On sign out, clear anything in browser storage or in memory that holds account data, such as lists, search text and drafts.
Offline or service worker cache, if you use one. Cache only account neutral assets such as scripts and styles. Never cache personal data responses there unless the key includes the account and the entry is removed at sign out.
Navigation history. Pressing Back after sign out must not reveal personal data from a restored page.
Server side checks. Every data request is authorised on the server for the current session, regardless of what the page already holds.

Branches by situation

Deliberate sign out and a different person signs in. Layers 2 to 4 are in focus.
Session expiry while the page is open. The next data call must fail cleanly and the page must hide data, not merely show an error beside it.
Two tabs open. Signing out in one must lead the other to hide data on its next action or at the latest at its next data call.
A shared proxy or content network in front. Layer 1 rules apply, and you should check them from outside the browser as well.

Worked hypothetical example

Staff A and Staff B share one machine. Rehearsal:

A signs in and opens the customer list. Expect 3 customer rows belonging to A's team (a seeded test set).
A types a search term, opens a customer, and signs out. Expect the sign in screen with an empty search box on return.
Press Back. Expect the sign in screen or a redirect, with no customer name visible, even briefly.
B signs in and opens the same list URL. Expect 2 rows from B's seeded team and none of A's three.
Open the customer URL A had visited. Expect a refusal for B, from the server.
Inspect stored browser data. Expect no entries naming A's customers.
With a second tab left open on A's list before sign out, interact with it after B signs in. Expect it to hide data and ask for sign in, without showing B's data under A's page.

If any step shows A's data to B, even for a moment, record which layer failed and stop the rollout.

Stop conditions

Any personal data visible to the wrong account.
A route with no recorded caching decision.
Sign out that cannot confirm it cleared client storage.

Do not ship a change that fails these. Fix the layer, then rerun the full script, because a fix in one layer can alter another.

Proposed acceptance tests (to be run, none performed here)

Run the seven step rehearsal with seeded data and expect the observations above.
Repeat with session expiry in place of sign out.
Repeat with the service worker disabled and enabled, if used.
Request A's data URL with B's session from a command line client and expect refusal.
Check response headers on each authenticated route against your decision table.
Repeat after any change to caching, routing or sign out code.

These rules stack several imperfect constraints. Each one reduces exposure, and none removes it alone, so the rehearsal should stay part of every release that touches sign in, caching or navigation.