Logout for shared-device MENA apps: a handover guide

A receptionist signs out of a shared tablet. The next person presses Back and sees the previous customer's record. Another tab still has an editable form, and a delayed request is about to put old data back on screen.

A login-page redirect does not settle any of those problems. For a MENA business application used across shifts, logout needs an explicit contract covering server access and what remains on the device.

This guide proposes that contract for an Arabic-English service portal with server-managed browser sessions. A Saudi branch and a UAE branch are hypothetical deployments with their own device policies, not interchangeable legal environments. The design below is an engineering playbook, not a claim of regulatory compliance or a tested product implementation.

Cover: original SultanByte artwork showing server-session revocation and browser cleanup as separate logout responsibilities.

Define what the button promises

Start with a product decision: does the button end this browser session, every session for the account, or an identity-provider session as well? Name the scope in the interface. Do not label a local application action "sign out everywhere" unless the implementation covers that promise.

For the proposed shared-tablet portal, define completion as a confirmed server-session revocation plus removal of the account's accessible application state on that device. Keep a separate incomplete state when either responsibility cannot be confirmed. The user should not be told the tablet is ready for handover merely because navigation succeeded.

OWASP's session-management guidance requires server-side invalidation when users log out. Deleting a browser cookie alone does not implement that server action. Use the session facility's supported revocation operation and expire the corresponding browser cookie with the correct scope.

In this design, protect the logout endpoint against cross-site request forgery and make repeat requests safe. Record the outcome without recording the session secret. If the service uses access and refresh tokens instead of a server-managed session, specify their revocation and remaining-validity behaviour separately before adopting this contract.

Stop old work before showing a new account

Treat logout as a state transition, not just a route change. Immediately hide sensitive views, disable account-bound actions and stop scheduling new requests. Cancel outstanding client work where possible, but also invalidate its permission to update the interface.

Give each authenticated client context a generation. Capture that generation with every request. A result may update the UI only if its generation still matches the active context. Advance the generation on logout and account change; apply the check to errors and final cleanup as well as successful responses.

This is a proposed application invariant. It addresses a specific race: a request started by user A finishes after user B signs in. Clearing a query cache at logout is insufficient if A's response can refill it afterwards.

Define the boundary for operations already accepted by the server. In this design, logout blocks later authorization checks; it is not a cancellation request for an accepted job. If a high-risk action must stop at revocation, add a server-side check at its commit boundary and test that race separately.

Keep the screen locked while the server outcome is uncertain. If the connection fails, explain that the device has been locked locally but server sign-out is unconfirmed. Offer a bounded retry or an approved support route. Do not silently restore the old view to make the error disappear, and do not delete the only information needed for a safe revocation retry without a recovery design.

Separate HTTP caching from application storage

For sensitive HTML and API responses in this portal, use an explicit Cache-Control: no-store response policy and verify the headers through the deployed delivery path. Keep public images and application assets under a separate caching policy.

RFC 9111 distinguishes the directives: no-store prohibits storage by conforming HTTP caches; no-cache permits storage but requires validation before reuse; private excludes shared caching while still allowing a private cache to store the response. They are not interchangeable logout controls. The RFC also warns that no-store is not a sufficient privacy guarantee.

Browser application storage requires its own inventory. MDN's Cache documentation states that the Cache API does not honour HTTP caching headers. A service worker that explicitly stores a sensitive response therefore needs an application policy beyond the origin's no-store header.

For this design, exclude account responses from offline response caches. Identify any existing account data in IndexedDB, local storage, session storage and in-memory query stores. Assign a cleanup owner to each store. Prevent active tabs and workers from writing old-account data while cleanup runs; otherwise an apparently successful deletion can be followed by repopulation.

Do not treat a successful logout response as proof that every client-side deletion completed. Record failures, keep the device in its locked handover state and provide a recovery path that does not expose the previous account.

Original infographic: SultanByte. Proposed engineering framework informed by OWASP, IETF RFC 9111, W3C, WHATWG and MDN documentation, October 2026. The checks are design requirements, not measured results.

Use Clear-Site-Data with a known scope

The W3C Clear Site Data draft defines a response header for requesting browser cleanup. Its types distinguish cache, cookies and storage. This can supplement application cleanup, but the scope deserves review before adding it to a logout response.

In particular, the specification's cookie-clearing algorithm covers the registered domain, including related subdomains. Storage clearing is associated with the response's origin. A response from an API origin should not be assumed to clear a separate frontend origin's IndexedDB. Conversely, broad cookie clearing can affect sibling applications that share the domain.

Map those boundaries explicitly. List the frontend origin, API origin, authentication origin and sibling applications. Decide whether broad clearing is appropriate or whether the application needs targeted cookie expiration and explicit deletion of its own stores. Avoid introducing a domain-wide cleanup as an unreviewed frontend patch.

MDN's header reference documents the secure-context requirement and browser compatibility. Validate the selected directives on supported browsers and embedded webviews. Keep an application cleanup path and test its outcome; a header appearing in the network panel is not evidence that the required data disappeared.

For the proposed portal, document which origin returns the cleanup response and which stores that response is expected to affect. Review any retained language preference separately from account information so that a harmless Arabic interface preference does not become an excuse to retain customer records.

Recheck tabs that missed the logout

The HTML Standard's BroadcastChannel mechanism supports notifications between eligible contexts with matching storage keys and channel names. The standard includes a logout-notification example. Use such a message to tell participating tabs to lock and discard their account state, not as proof that the server revoked access.

In this design, messages contain only a small invalidation signal, not credentials or customer data. A receiving tab moves to an unverified state and checks the server before enabling account actions again. The tab initiating logout must update itself too.

Do not depend on receiving a broadcast. MDN documents pageshow for navigation and restoration, including Back/Forward restoration and frozen mobile pages. It separately points to visibility events for changes in whether a page is shown.

Require a session check when restoring or reactivating a sensitive view. Keep that view covered until validation completes, and apply the same generation guard to the validation response. Review pre-hide handling and test the actual browser transition: a handler that runs after restoration must not be advertised as a guarantee that old pixels can never appear.

For a strict shared-device workflow, make absence of visible prior-account content an acceptance condition. If a browser or device cannot meet it reliably, restrict that workflow to an approved managed environment rather than weakening the handover promise.

Resolve unsent work before handover

Logout can destroy work if cleanup includes unsent forms. Decide that policy before implementing deletion. Before the committed logout transition, offer synchronization or deliberate discard after a clear warning. Keep an immediate sign-out path with the documented discard consequences; do not force someone to remain signed in until a network returns. Handover remains blocked until the chosen logout path completes.

If the product permits retained offline drafts, that is a different security design. It needs a reviewed access boundary, recovery policy and device model. Do not send user A's retained operations under user B's newly established session. SultanByte's offline-forms guide covers the separate queue and conflict contract.

Use the same engineering review for Saudi and UAE deployments, but approve device-sharing and retention policies separately for each customer. Country labels alone do not determine who may keep an offline copy. Product owners should make the pending-work warning understandable in both Arabic and English, including an explicit distinction between discarding a local draft and cancelling an operation already accepted by the server.

Test a handover, not a redirect

Use synthetic accounts A and B with visibly different records. Run the following proposed acceptance cases through the deployed gateway, session store and supported browser combinations. These are test requirements, not reported benchmark results.

• Open two tabs as A, sign out in one, then attempt a protected read and write from the other. Require server denial and a locked interface.

• Hold A's data response, complete logout, sign in as B, then release the delayed response. Require no A data in B's screen or client stores.

• Navigate Back and Forward, restore a suspended tab and reopen the application. Inspect visible content as well as network responses.

• Interrupt the logout request before confirmation. Require an honest unconfirmed state rather than a successful-handover message.

• Exercise cleanup with a worker active and with another tab holding storage open. Require failures to remain visible and old data not to be repopulated.

• Leave unsent work, then attempt logout and account switching. Require the documented retain, synchronize or discard policy without cross-account submission.

• If using Clear-Site-Data, inspect the intended stores and sibling applications. Confirm both cleanup and the absence of unintended domain-wide disruption.

Record browser and app versions, the starting session scope, server revocation evidence, remaining stores and the visible result. Keep session values out of that report.

For a CTO buying a shared-device portal, ask the supplier to demonstrate this handover using two test accounts. For the implementation team, release only when the server rejects the old session and the approved device no longer exposes its account state. A return to the login screen is just one observation in that demonstration.