A tiny script injected into the page head that wraps the browser's storage getter, setter and remover so every key is prefixed with the current subdomain. It runs synchronously before the app hydrates, so all subsequent application code is prefixed automatically without any call site knowing about it.
Also called: localStorage prefix · leftover data on a subdomain · browser storage scoping
- 1The script derives the subdomain from the hostname, skipping localhost, bare IPs and reserved labels.
- 2getItem, setItem and removeItem are redefined to prepend '<subdomain>::' to every key.
- 3The property descriptors are marked configurable and writable, which is required so development tooling that proxies the storage object doesn't throw.
- 4The apex is intentionally left unprefixed so the original account's existing preferences survive untouched.
- 5It installs once per page and marks itself so it can't double-wrap.
The comment is unusually candid that this is a belt over an already-working brace: 'localStorage is already per-origin in browsers, so cross-tenant bleed is structurally impossible. But during development we hit a window where server bugs wrote one tenant's data into another tenant's own localStorage… Even after fixing the server, that stale data persisted in the visited subdomain's localStorage.' Prefixing orphans those entries rather than requiring a cleanup migration. The descriptor detail is a real bug too: a plain value descriptor is non-configurable, 'which violates a JS Proxy invariant… once dev tooling wraps window.localStorage in a Proxy — any later localStorage.getItem read then throws on tenant subdomains.'
- Historic bad data written into a subdomain's storage outlived the server-side fix.
- A cleanup would otherwise require asking every user to clear site data.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →