Partitioned Cookies Limit Cross-Site Reuse, Not Cross-Site Risk
Cookies Having Independent Partitioned State, usually called CHIPS, gives a cookie a second key based on the top-level site. A service embedded in two different sites gets separate cookie jars for those embedding contexts. MDN describes the storage key as the host key plus a partition key derived from the top-level URL. The feature addresses cross-site tracking and cross-site state reuse. It does not make the embedded application trustworthy.
With the Partitioned attribute, a cookie must also be Secure. A typical header looks like Set-Cookie: __Host-example=...; SameSite=None; Secure; Path=/; Partitioned. The __Host prefix is recommended when the cookie does not need to be shared between subdomains. That combination gives the cookie a host binding and a top-level-site partition. It still does not decide whether the JavaScript running in the iframe should receive a session or whether the receiving endpoint should accept a request.
The remaining risk is easiest to describe with an embedded support widget. The widget stores a session cookie partitioned for each customer site. A script compromise inside the widget can read the cookie in the current customer partition and make requests as that session. The attacker does not need the cookie from another customer site. One partition is enough to reach the current user's data. Partitioning limits blast radius across embedding sites, while the origin's authentication and authorization still determine what the stolen session can do.
Teams should inventory third-party cookies by embedding relationship. For each cookie, record the setting origin, the Domain, the Path, the SameSite value, the Partitioned flag, and the top-level sites that are expected to embed the service. Review which JavaScript origins can read the cookie and which server endpoints accept it. A cookie that carries an authorization decision should use HttpOnly where possible and should be paired with CSRF defenses and origin checks.
The partition key is not a tenant identifier that the server can trust blindly. It is enforced by the browser and is not normally visible to the server as a verified claim. If the application needs tenant separation, it must derive the tenant from an authenticated server-side context, such as a signed session or a token bound to the tenant. Do not infer tenancy from the embedding site alone.
The feature also changes incident procedures. Clearing one unpartitioned cookie may not clear every partition. A logout flow should revoke the server-side session and send expiry headers for the known cookie names. Support teams should know how to enumerate the partitioned contexts when testing a widget. Browser debugging tools may show the partition key, but logs on the server will not necessarily contain it. Record both the embedding site and the service origin in client-side telemetry, subject to privacy controls.
Compatibility is another operational risk. MDN reports broad availability in recent browser versions, but older clients may not support the attribute. A fallback that silently drops Partitioned can restore the original cross-site sharing behavior. Test the exact cookie header across supported browsers and verify that the fallback is intentional. Do not treat a browser's acceptance of an unknown attribute as proof that partitioning occurred.
CHIPS is a useful privacy control because it reduces one kind of cross-site linkage. It does not replace least-privilege sessions, content security policy, iframe sandboxing, or careful third-party script review. The safe design uses partitioning to limit state reuse and separately asks what a compromised embed can do inside one partition. That second question is where most account and data risks remain.
Top comments (0)