Client Accounts Do Not Belong in Your Main Browser

We have not had a client session leak out of a shared browser profile, and we would rather write this before we do. The setup that produces one is ordinary: a laptop with one Chrome profile, fourteen client dashboards signed in, a password manager extension, a screenshot tool, a JSON viewer and something for taking notes. Every one of those logins shares a cookie jar, a storage directory and a set of extensions that were granted access to every page.

The usual advice treats this as a convenience problem: you cannot be signed in to two accounts at once, so use profiles. That is true, and it is the least interesting part. The real problem is that a single profile is a single security boundary, and most people are running fifteen clients inside it.

One cookie jar, every client

A browser profile stores cookies, local storage, IndexedDB, cache and service workers per site, and shares all of it across every tab in that profile. When you sign in to a client's admin panel, the session cookie lands in that shared store. When you sign in to your own account on the same service, one of the two sessions replaces the other, which is the annoyance everybody knows. The part that matters is quieter: any code running in that profile can read what is in the store.

That code is not only the site you are visiting. It is every extension you installed, every script those extensions inject, and anything that manages to run in a page you opened. A profile is not a compartment. It is one room with all the doors open.

What a leaked session actually grants

A session cookie is a bearer credential. The OWASP Session Management Cheat Sheet puts it plainly: the session ID is "temporarily equivalent to the strongest authentication method", and "anyone who can read it can reuse unexpired tokens". It also notes that deleting the cookie on your machine does not invalidate a copy someone else already has; only the server can do that.

So the question is not "what can someone see in this dashboard". It is "what could the person holding this cookie do as me, right now". On the dashboards a studio uses, the answer usually includes reading every record the account can read, changing DNS or deploy settings, inviting a new team member, creating an API key, and changing the billing contact. Several of those outlive a password reset: an API key minted from a hijacked session keeps working after you change the password, and an invited user stays invited until somebody notices.

Detection is poor by design. Reusing a session looks like the legitimate user from a new address, and many providers only alert on a new password or a new device. If the token came from your own laptop, there is no new device to flag.

Extensions see more than the tab you are on

Chrome's documentation on permissions lists what host access enables: reading cookies through the cookies API, injecting content scripts, monitoring and controlling network requests, and modifying request and response headers. An extension with broad host permissions is not watching one tab. It is watching the profile.

Now consider how extensions arrive and change. You install a screenshot tool for one task and grant it access to all sites because the prompt makes that the easy choice. It updates silently every few weeks. Its ownership can change hands. A dependency inside it can be compromised. None of these events asks you again, and none of them is visible in the toolbar.

The mitigation is not a careful reading of every permission prompt, although that helps. It is a work profile with no extensions at all, and a separate profile for browsing where extensions are allowed to exist. The two should never be the same window.

A private window is not a boundary

Private browsing isolates storage from your normal session and throws it away when the window closes. That solves the "second login" problem and nothing else. It is the same browser binary, the same profile-level configuration, the same network, the same downloads folder, and the same extensions if any of them are permitted in private windows.

It also fails in the direction that matters. A private window is designed to leave no trace on your machine, not to protect the session from the machine. If malware or a malicious extension is running as you, private mode is a fresh empty room in the same house.

Use private windows for a one-off check on a site you do not trust with a persistent cookie. Do not use them as the place where client accounts live, because you will log in again tomorrow, and the habit of doing that inside your main profile is exactly how the sessions end up in the shared jar.

What real isolation looks like

Isolation means four things are separate, not one. Storage: cookies, local storage, IndexedDB, cache and service workers. Process: the browser instance handling the account is not the one handling everything else. Credentials: the saved passwords for that account are scoped to it. Extensions: the code that can read the page is not shared with every other identity.

A separate Chrome profile gives you the first, most of the second, and a separate password store. Google's own help page says that with profiles you "can keep all your Chrome info separate, like bookmarks, history, passwords, and other settings". That is a real boundary and it is the minimum anyone doing client work should use: one profile per client, named after the client, never mixed with the personal one.

What a profile does not give you is a boundary against your own operating-system user. Every profile on the machine is readable by any process running as you, including a profile you have not opened today. If the threat you care about is malware on the laptop, the next step up is a separate OS user account, a virtual machine, or a dedicated application that keeps each account in its own storage partition and its own process. That is more friction, and it is the honest answer for anyone holding credentials to a client's production infrastructure.

The rules we actually follow

• One profile per client, created before the first login, named so you can tell at a glance which window you are in.
• No client account ever signs in inside the personal or the browsing profile, not even "just once".
• The work profile has no extensions. If a task needs one, it happens in the browsing profile, not next to client sessions.
• No shared passwords. Ask the client to invite you to their team, workspace or organisation, so access can be revoked without changing a secret that other people also know.
• Two-factor authentication or a passkey on every account that offers one, including the client's.
• When a contract ends, close the profile, remove the saved logins and ask the client to remove your access. Deleting your copy does not end their session.
• Once a quarter, open the extension list and remove anything you cannot explain.

None of this is exotic. It is the same discipline as keeping production credentials out of a shared notes app, applied to the place where the credentials actually live.

If the problem is only switching accounts

There is a separate, smaller problem: you want to be signed in to six accounts at once without logging out. Profiles, container tabs, team switchers and dedicated apps all solve it, with different trade-offs in memory and habit. We wrote about those options in managing multiple cloud accounts without logging out. Read that one if convenience is the goal. Read this one if the question is what a single compromised session would cost you.

The distinction matters because the convenient option is not always the safe one. A tab that shows six dashboards side by side is a nice interface over one shared cookie jar unless it genuinely partitions storage per account. Ask which of the four separations it gives you before you trust it with a client's production login.

One way to do it

We built My Provider Dash Manager because we wanted one window for client accounts with a real storage boundary between them: a separate persistent Chromium partition per account, no shared extensions, saved logins scoped to each service's own domains. It is one implementation of the idea, and the idea is what matters. A browser profile per client, created on purpose and removed when the contract ends, already removes most of the risk described here.