News
Shared Storage API vs Topics API for Marketing Sites
November 14, 2025
Shared Storage API vs Topics API for marketing sites is two Privacy Sandbox ads channels. Topics lets participating sites observe coarse interest topics the browser computed. Shared Storage lets an origin write data that later runs in a worklet — often with a fenced frame — so select outputs can be used without a third-party cookie jar. Neither is access control. A brochure that needs pageviews can stay on first-party analytics and skip both. Permissions-Policy can restrict shared-storage and browsing-topics. RoastMyOpsec pattern-matches common analytics and marketing hosts in public HTML. It does not score Shared Storage, does not run worklets, and does not treat missing Shared Storage as an F.
The practical difference
Topics is a coarse interest signal. Shared Storage is origin-keyed storage that is not freely readable by the page the way localStorage is — outputs are gated. Attribution Reporting measures conversions. Fenced frames are the opaque embed. Unpartitioned cookies are the old shared jar.
Pasting a Shared Storage snippet because 'cookies are dying' still adds a third-party script unless you control the worklet.
How to choose a measurement plan
Need counts on your own site: first-party analytics. Need ads frequency or A/B in a Privacy Sandbox stack: Shared Storage after a vendor and privacy review. Need interest categories: Topics, same review. Use Permissions-Policy to disable unused shared-storage and Topics if you do not participate.
| Channel | What it holds | Brochure default | Takeaway |
|---|---|---|---|
| Topics API | Coarse interests | Skip unless you sell ads | See Topics vs cookies |
| Shared Storage | Worklet-gated origin data | Skip unless you run ads | Not a roast F if missing |
| First-party analytics | Your origin's counts | Usual win | See trackers vs first-party |
| Fenced frames | Opaque ads embed | Skip unless required | See fenced frames vs sandbox |
When Shared Storage still wins
It wins as a vendor requirement on a site that already runs ads and has a privacy review. First-party analytics still wins for a brochure. Missing Shared Storage is healthy. Pair with fenced frames if the output is meant to stay opaque.
What the roast can prove
Known tracker hosts in HTML can surface. Shared Storage participation is not scored. Confirm Permissions-Policy and scripts yourself. Pair with consent-based scanning — do not roast third-party ad hosts as research.
Common mistakes
The first mistake is treating Shared Storage as a replacement for HttpOnly session cookies.
The second mistake is requiring window.sharedStorage as an OPSEC finding.
The third mistake is leaving shared-storage wide open in Permissions-Policy when you do not use it.
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
- Is missing Shared Storage a vulnerability?
- No. It is an ads measurement choice. Missing it is not a roast F.
- Does Shared Storage replace Topics?
- No. Topics is coarse interests. Shared Storage is worklet-gated origin data. Brochures usually want neither.
- Does RoastMyOpsec call Shared Storage?
- No. It may pattern-match known marketing hosts in HTML. It does not run worklets.