Playwright Browser Contexts: Isolation and Network Interception
A Playwright browser context gives a job its own browser session within a browser process. That makes it useful for separating test accounts, provided the rest of the workflow also respects account and data boundaries.
One context per isolated session
Playwright describes browser contexts as independent, incognito-like sessions. Pages within one context share that context's session state; another context has a separate session. Create a fresh context for each test identity or customer job, and close it when the job ends. Sharing a page or context across identities defeats that separation.
This is browser-session isolation, not a substitute for separate backend permissions, process isolation or tenant controls. A job can still send data to the wrong destination if its own code chooses the wrong account or URL. Keep authentication state files private and don't put cookies or tokens in logs.
Inspect a request before changing it
Playwright's network guide documents request and response events and routing at page or context level. For a test of a site you control, start by observing the specific request that carries the data you need. Decide whether the job should wait for a particular response, use a documented API, or handle an explicit error.
Routing can fulfill, change or abort matching requests. Broadly blocking scripts, images or other resources can change page behavior or omit data, so test the exact rule against representative pages and keep a way to disable it. The guide also notes that service workers can affect which requests are visible to routing; blocking service workers changes the environment and should be a deliberate test setting, not an unexplained production assumption.
Keep state handling deliberate
Playwright can save and restore selected authentication state. Follow its authentication guidance for the framework version in use, and treat the saved file as a secret because it can contain material that impersonates the account. Restoring a session doesn't guarantee it remains valid, renew a one-time challenge token or grant access that the account doesn't already have.
For an authorized workflow, check identity after loading the session and handle expiration as a normal failure. Don't reuse another person's profile or attempt to evade access controls. Review the service's limits and use a supported integration when one fits.
Example: isolate a test and block images
from playwright.sync_api import sync_playwright
with sync_playwright() as playwright:
browser = playwright.chromium.launch()
context = browser.new_context()
try:
page = context.new_page()
page.route("**/*", lambda route: route.abort()
if route.request.resource_type == "image"
else route.continue_())
page.goto("http://127.0.0.1:8000/")
finally:
context.close()
browser.close()
Run this only with an owned test server listening on the local address. The image rule can change the result if the application relies on images; compare with an unmodified context. A failed navigation or a changed result is a test failure to investigate, not proof the route is safe for production.
If you need help planning an authorized automation workflow, ask for a scoped assessment. Share the documented limits and a redacted example, without credentials or private data.