SameSite and CHIPS: Cookie Sending Rules and Partitioned Storage
SameSite limits cookie sending by request context; CHIPS separates an embedded service’s cookie state by top-level site. Here is how the controls differ and what to test.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
Start with two different problems
HTTP cookies let a site maintain state such as a sign-in or preference across requests. When a widget, payment tool, or map is embedded on other sites, two questions arise: under what request contexts should a cookie be sent, and should the embedded service share one state across those sites?
SameSite is a request-context policy that limits cookie sending on same-site versus cross-site requests. CHIPS—Cookies Having Independent Partitioned State—lets an embedded service opt into cookie storage separated by top-level site. One changes sending rules; the other partitions stored state. They are related controls, not synonyms, and they can be used together.
What SameSite changes
The IETF HTTP Working Group’s RFC6265bis draft describes Strict, Lax, and None behavior. Strict is more restrictive for cross-site requests; Lax permits certain top-level navigation flows; and None marks a cookie for cross-site use and must be paired with Secure. The exact result still depends on the request and browser implementation, so test the flows the application actually uses.
SameSite is defense in depth against cross-site request forgery (CSRF), not a complete security boundary. It does not replace authorization checks or dedicated CSRF protections for state-changing operations. Site boundaries and navigation, redirect, and form behavior also matter; assuming every cross-site request is blocked can leave gaps.
How CHIPS separates embedded state
Google Privacy Sandbox documentation describes CHIPS as opt-in partitioned storage. With the Partitioned attribute, an embedded service’s cookie is kept in a partition associated with the top-level site. The same comment widget embedded on two different publishers can therefore maintain separate state in each publisher context instead of automatically sharing one cross-site cookie.
The documentation’s example has the form Set-Cookie: __Host-example=123; Secure; Path=/; SameSite=None; Partitioned. SameSite=None allows the cookie to participate in a cross-site embedded request; Partitioned separates its storage by top-level site; Secure requires a secure connection. If a required attribute or browser condition is missing, the cookie may not be stored or sent as expected. Inspect both the response header and the browser’s cookie store.
Expert perspective: CHIPS is not a universal privacy or CSRF fix
Partitioning supports embedded services that need site-specific sessions or preferences without one shared cookie across every top-level site. It changes a storage boundary; it does not automatically anonymize cookie values, erase application data, or repair an authorization flaw. First-party behavior and other data flows, such as server logs, still need their own privacy analysis.
Nor does Partitioned complete a CSRF defense. SameSite and CHIPS address different axes and neither replaces authentication, authorization, request validation, or safe state-changing design. Confirm the effective partition key and that the site boundary matches the product’s intended behavior, including subdomains and embedded contexts.
A practical implementation check
Decide whether the feature truly needs state shared across top-level sites. If it should be separated, evaluate whether CHIPS fits the use case and verify that the server emits the intended Partitioned, Secure, and SameSite attributes. Exercise sign-in, redirects, new tabs, cross-site forms, and embedded frames in the browsers your users actually use.
Browser support and default policies evolve. The cited IETF document is RFC6265bis draft-22 from December 2025, not a published RFC; its page lists an expiration date of June 4, 2026. Check the Datatracker status and current browser documentation before treating it as current normative guidance. Test Google’s documented CHIPS behavior in each target user agent as well.