Infrastructure / Guide
Browser session isolation
Distinguish browser contexts from process, storage, and network isolation.
Browser session isolation prevents one workload from accessing or interfering with another workload's browser state and resources. The important question is which boundary a design enforces: website storage, operating-system processes, persistent files, network access, or tenant authorization.
Start with the boundary you need
| Boundary | Protects against | Still needs attention |
|---|---|---|
| Browser context | Accidental sharing of cookies and site storage | Shared process resources and infrastructure access |
| Browser process or container | Some process and filesystem interference | Host hardening, resource limits, network policy |
| Profile ownership | Reusing another account's saved state | Authorization on every profile operation |
| Gateway authorization | Attaching to another tenant's browser | Credential expiry and endpoint leakage |
| Network policy | Unwanted access from the browser environment | DNS, redirects, proxies, and private address handling |
A browser context is useful for separate browsing state. It should not be treated as equivalent to a hardened tenant boundary. Playwright describes context-level test isolation in its browser contexts documentation.
Separate identity from concurrency
Giving each task a different tab does not separate accounts. Tabs within the same context can share cookies and storage. Give tasks the appropriate context or browser allocation, and keep account profiles under explicit ownership.
Set a maximum number of active sessions per tenant and a per-session resource budget. A workload that consumes all memory can disrupt neighbors even without reading their data. Track crashes and rejected allocations alongside successful task completion.
Protect paths outside the browser
Browser isolation alone does not protect a shared download folder, recording bucket, or viewer URL. Scope artifact storage to the session and tenant. Avoid predictable access paths without authorization, and make retention policies explicit.
The network deserves its own policy. A browser can issue requests from the environment in which it runs. If it processes untrusted URLs, restrict access to internal services and metadata endpoints through infrastructure controls. Page-level navigation rules are not a replacement for that network boundary.
Verify isolation through observable behavior
Use test accounts to check that one session cannot see another account's cookies, list another tenant's profiles, retrieve another recording, or attach with an unrelated credential. Repeat checks for expired credentials and after a session is released. Use resource-pressure tests to verify quotas and failure containment.
These are evaluation criteria rather than a claim that a particular deployment passes every check. Review Remote Browser security and the architecture for product-specific boundaries. Continue with persistent profiles when designing reusable account state.