Cookies Having Independent Partitioned State, usually called CHIPS, lets a site opt a cookie into storage that is keyed by the top-level site and the cookie's host. The Partitioned attribute changes how a browser stores and returns the cookie. It does not change the application's responsibility to authenticate the user, authorize an object, or separate tenant data.

That distinction matters for embedded portals, support widgets, payment forms, and any application that runs inside another site. A partitioned cookie can prevent one top-level site from seeing another site's copy of the same embedded service cookie. It cannot prevent an application flaw inside one partition, a stolen bearer token, or a server that returns data for the wrong account.

Understand the storage key

MDN describes partitioned cookies as using the host key and a partition key derived from the top-level site. Two top-level sites that embed the same third-party service receive different cookie jars even if the cookie name and host are identical. The Partitioned attribute is set on the Set-Cookie response, and the cookie must also use appropriate security attributes.

The partition key is not a user identity or a tenant identity. It is a browser storage boundary. If the same user visits the same embedded service from two sites, the service may see two independent cookie contexts. If two users share a device and visit the same top-level site, they may still share the browser profile. Design session records and logout behavior from those realities.

Do not use a partitioned cookie as the only source of tenant context. The server should resolve the tenant from an authenticated session, a signed configuration, or a validated host mapping. A request from a different top-level site should not be able to move the session to another tenant merely by changing a cookie name or an embedding parameter.

Plan for compatibility and fallbacks

Browser behavior around third-party cookies differs by vendor, version, user setting, and enterprise policy. Some contexts may reject the cookie entirely. Others may use partitioning only when the attribute is present. A service that depends on a cookie for authentication needs an explicit fallback for a lost cookie, such as a short-lived authorization code or a reauthentication flow.

Test in a real embedded context rather than only at the top-level URL. Check whether the browser sends the cookie, whether it sends it only in the expected partition, and whether a logout in one top-level site affects another partition. Test SameSite interactions, secure transport, and a top-level navigation that changes the embedding site.

If the service uses a cross-site iframe for login, do not weaken the cookie to SameSite=None without Secure and a reviewed domain policy. Do not expand the cookie domain to a parent domain merely to make an embed work. That is a different security tradeoff and can expose the cookie to more subdomains than intended.

Keep authorization on the server

The session should carry the user, tenant, assurance level, and expiry. The server should check the requested resource against that session on every request. A partitioned cookie might distinguish two embedding contexts, but the server still needs a mapping between the embedding context and the authorized tenant.

Use __Host- prefixes where they fit the deployment and help prevent domain and path surprises. Avoid storing personal data or access tokens in cookie values. A random session identifier is easier to revoke and rotate. Set a bounded lifetime, rotate after privilege changes, and invalidate the server session on logout.

Monitor missing-cookie rates by embedding site and browser. A change in partitioning policy can look like a login failure, a session loop, or an unauthorized request. Record the top-level site only when the privacy policy permits it, and aggregate the signal. Do not build a cross-site identifier from partitioned session records.

Treat partitioning as one control

CHIPS is useful when a service needs a cookie in a third-party context and wants to reduce cross-site tracking and cookie leakage. It is not a complete same-origin policy for application data, a substitute for CSRF protection, or a reason to trust an iframe's origin. The application still needs origin checks, CSRF defenses where cookies are used, and server-side object authorization.

The practical goal is to make the browser boundary explicit and keep the security boundary on the server. A partitioned cookie can be a reliable session container when the deployment accounts for compatibility, logout, tenancy, and token theft. It cannot manufacture those properties by itself.

References