Safety
Storage Access API vs Partitioned Cookies for Embeds
January 4, 2026
Storage Access API vs partitioned cookies for embeds is two answers to third-party cookie restrictions. Partitioned cookies (CHIPS) keep a SameSite=None cookie in a jar keyed by the top-level site, so site A and site B do not share the embed's identity. The Storage Access API lets an embedded origin request access to its unpartitioned first-party cookies after a user gesture, typically for a documented widget that already has a first-party relationship. Neither is a reason to mark the main login cookie None. Brochure sites that are not embeds should ignore both. RoastMyOpsec grades Set-Cookie on a consented GET. It does not call requestStorageAccess, does not load you in a third-party iframe, and does not prove CHIPS isolation.
The practical difference
Partitioned is a cookie attribute: if you send it third-party, isolate it per top-level site. Storage Access is a JavaScript prompt-shaped API: the embed asks to use its unpartitioned cookies in this embedding context after the user interacts. Unpartitioned None without either is the old shared tracker jar.
If the cookie is wordpress_logged_in on your own origin, keep Lax or Strict. See SameSite=None vs Lax and partitioned cookies vs None.
How to choose based on the embed's job
You are not an embed: do not set Partitioned on session cookies and do not call the Storage Access API. Widget that must remember a preference per host: Partitioned + None + Secure, dedicated name. Widget that must continue a first-party login inside a partner iframe after a click: Storage Access on that flow, still CSRF-defend state changes, still not the marketing homepage session. Marketing pixels: prefer first-party analytics instead of either knob.
| Control | Jar | When it wins | Takeaway |
|---|---|---|---|
| Lax / Strict session | First-party | Your site's login | Default |
| None; Secure; Partitioned | Per top-level site | Widget cookie that must exist in iframes | Better than unpartitioned None |
| Storage Access API | Unpartitioned, after gesture | Documented embed with a first-party relationship | Not a tracker toggle |
| Unpartitioned None, no API | Shared across sites | Legacy you have not migrated | High CSRF and tracking cost |
When Storage Access wins
Storage Access wins when the user already has a first-party account with the embed origin and a click is a reasonable gate. Partitioned wins when you only need a per-host widget cookie and should not join a global profile. First-party Lax still wins for the brand's own session.
What the roast can prove
Landing Set-Cookie flags, including Partitioned if present. Storage Access is a runtime API — it will not show on a header scan. Confirm embed cookies in your own staging iframe. Pair with third-party trackers vs first-party analytics if the 'embed' is a pixel.
Common mistakes
The first mistake is calling requestStorageAccess to restore a tracking cookie the browser already partitioned.
The second mistake is Partitioned plus Storage Access plus None on the same session cookie 'to be safe.'
The third mistake is treating a roast miss on Partitioned as proof the embed jar is correct.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Do brochure sites need the Storage Access API?
- No. It is for embedded origins that must reach unpartitioned cookies after a user gesture.
- Is Storage Access the same as CHIPS?
- No. CHIPS partitions the cookie jar. Storage Access requests the unpartitioned jar in an embed after interaction.
- Does RoastMyOpsec call requestStorageAccess?
- No. It reads Set-Cookie on a consented GET. Confirm embed behavior in your own staging iframe.