Unique cookies and local storage need checked workspace boundaries, not just different labels. Prepare an owned test app, the intended browser contexts and nonsecret values. The result should show which context and origin holds each value. Keep real login data out of the review.
Two account workspaces may look separate while a preference changes in both. First check the tool's storage boundary rather than guessing that a proxy caused it. This is a proposed review, not a live social-account test or a certified Moimobi isolation result.
Key Takeaways
- A new cookie name is not a new browser workspace.
- Cookie sending scope differs from localStorage's origin boundary.
- URL paths are not separate localStorage containers.
- Check a value in the intended context and origin before calling it missing.
- Use harmless markers rather than exported authentication data.
Prepare unique cookies and local storage checks
Start with the claimed boundary. Does the tool assign a separate profile, a separate context or just another tab? Ask for its documented state-handling contract. A colored window or account nickname does not explain where data lives. You need an owned app with test controls, not access to another site's login values.
Prepare these inputs:
- One application and origin you control.
- Two designated contexts, labeled A and B for this review.
- One harmless storage key and two distinct marker values.
- The browser/tool version and supported profile controls.
- Expected results and a reviewer who can inspect a mismatch.
Set a browser workspace isolation requirement, then verify the tool's actual behavior. A product category name does not establish its storage contract. Keep account-to-workspace assignments separate from fixture values. The review should not look like a list of live credentials.
Compare the storage boundaries, not just the values
MDN describes localStorage as storage for a document's origin. Its values persist across browser sessions; HTTP and HTTPS use different localStorage objects. A missing value may therefore mean the reviewer opened a different origin rather than lost the original data. MDN localStorage reference
| Review question | Cookies | localStorage |
|---|---|---|
| What scope should I inspect? | Host/domain and matching request path | Document origin within the browser's storage context |
| Does a different URL path create separation? | Path changes sending eligibility, not a security boundary | No separate path-level container |
| Is a different key enough? | A distinct name does not create a profile | A distinct key does not create a context |
OWASP explains that an explicit cookie Domain can include subdomains. Omitting it limits the cookie to the origin server. Path limits matching requests but does not make same-host apps secure from each other. Inspect the scope rather than treating two cookie names as proof of separate account state. OWASP cookie scope guidance
Leave a social site's cookie settings unchanged. For tool selection, ask which state containers your permitted task needs. Then ask how the supplier demonstrates that boundary. A different stored value is not enough to answer either question.
Test unique cookies and local storage with nonsecret markers
Use the same owned first-party origin throughout this proposed check. Changing both the context and the origin at once would make an unexpected result harder to interpret. The fixture below concerns localStorage only; it does not certify cookies, third-party partitions or every storage API.
- Confirm context A. Open the owned application through the tool's normal context controls. Record the origin and the designated context before writing anything.
- Set a harmless marker. Use a test key such as
workspace-reviewwith valuescope-a. These are invented fixture labels, not tokens or observed results. - Inspect context B before writing. Open the same origin through the other designated context. Record whether that key is absent, present or unreadable. Unexpected presence needs investigation.
- Give B its own marker. Through the owned application's test controls, assign
scope-bto the same key. Reopen A and inspect its value again. - Compare and clean up. Check both findings against the claimed boundary. Remove only the fixture key through the approved test controls when finished.
MDN documents setItem as writing or updating a key, getItem as reading it and removeItem as removing it. The steps are an unexecuted review design, not a script to paste into a logged-in third-party site. Storage method examples
Verify a boundary without claiming complete isolation
Write separate expected and observed fields for each context. Before inspection, a proposed row reads "A: expected scope-a; observed: not tested." B should retain scope-b under the same claimed contract. Keep the observation blank or marked untested until someone reads it. A planned result cannot stand in for evidence.
For cookies, use a separate owned-app fixture. Inspect the supported cookie view, scope and relevant requests. OWASP notes that HttpOnly blocks script access through document.cookie. An empty read there is therefore not a full inventory. Cookie access limits
Retain observations, not secrets. A review note can say which fixture key changed and where. It should not contain session values or a full authentication export. A passed marker check covers that tested path, not fingerprint uniqueness, remote account independence or future login acceptance.
Unique cookies and local storage: limits and failed checks
An unreadable value is not an empty store. MDN documents errors for invalid origins or blocked persistence. It warns that file: URL behavior is undefined. First confirm the served test origin, then inspect the browser policy. Log an access error separately from an absent key. Storage access exceptions
Separate names cannot repair a shared boundary. Keep the same test key; changing it would alter two variables. If a value is shared unexpectedly, pause and check the context mapping first. Then repeat only the corrected fixture. Renaming the key or clearing all data first would hide the original symptom.
A stored account label is not permission. OWASP advises against trusting localStorage for access control or keeping session identifiers there. Scripts can read its data. Check access through the app's supported controls instead of accepting a saved label as proof. OWASP HTML5 storage guidance
Use the Moimobi technical reading collection for broader evaluation. Confirm current product behavior separately; these browser facts do not certify a supplier's implementation.
Frequently Asked Questions
What do unique cookies and local storage mean here?
They mean state assigned to an intended workspace with its scope checked. Different text values alone are insufficient.
Are two paths on one site separate localStorage areas?
No. Check the origin and actual storage context, not the path alone.
Should I change a social site's cookie attributes?
No. Use an owned test application for scope checks and leave production cookies untouched.
Can I use real session tokens as test markers?
Use harmless fixture values instead. The review does not need credentials.
Does an empty JavaScript cookie read prove separation?
No. Inspect the appropriate cookie view and scope rather than relying on that read alone.
What if B's write changes A's marker?
Stop acceptance and inspect context mapping. Record the mismatch before changing the setup.
Does this check prove accounts cannot be linked?
No. It evaluates a specific local storage path, not every signal or a platform's account decision.
Conclusion
Map the state container before comparing values. Review cookie scope separately, then inspect the claimed workspace boundary with a nonsecret same-origin fixture. Keep absent keys, access errors and unexpected shared values as different findings. Resolve them before relying on the boundary for account work.
