Browser credential storage boundaries

Each apartment visit gets a fresh note; the building keeps a tenant noticeboard. The concierge uses a master key for service, but residents never see it. Erasing a noticeboard entry does not void the master key.

Apartment detail	Browser boundary
fresh apartment note	page global (step 1)
tenant noticeboard	localStorage (step 2)
master key unseen by residents	HttpOnly cookie (step 4)
concierge service order	browser request attachment (step 5)
erase noticeboard entry; master-key service permission remains	local cleanup is independent of cookie (step 7)

Breaks down when: the concierge suggests request safety. Cookie attributes, intent validation, and XSS controls are separate.

4.1 ExamHall: keep interface preferences separate from credentials

EXH-1920 is a synthetic browser-storage case: a results reviewer had used durable origin storage for a credential. MR !2120 changes the storage contract so that JavaScript stores harmless interface preferences. The browser session and any server-held upstream credential have separate responsibilities. This is a placement decision, not proof that a complete production authentication system is secure. OWASP

In the executed preference fixture, the page stores export format csv and theme lime, then overwrites export format with json. It retains two entries rather than appending another entry for the changed format. The theme survives because it has a different key. These are non-secret preferences, not session markers. MDN

preference overwrite: format=json theme=lime entries=2

The observation establishes a specific key/value operation. It does not make localStorage a safe credential vault. The application must first classify the value: a layout preference can tolerate disclosure under a different policy from a value that authorizes account access. A short-lived copy still needs that classification; lifetime and readability answer different questions. OWASP

4.2 Payments preferences: the origin is part of the storage boundary

The same Chromium context visits a second fixture origin on another loopback port. That document initially has no theme entry. It stores lavender under the same key, while the original origin still reads lime. Both observations run in real pages; the script compares values and never uses a timeout to decide the result. MDN

different-origin preference: initial=null own=lavender original=lime

The two equal key names do not identify one shared entry across different origins. Conversely, creating another document within the same origin does not by itself create a separate localStorage namespace. Document lifetime and origin identity must be reasoned about separately. This example changes origin; it does not establish a cookie sending policy, which belongs to the linked cookie pack. MDN

Their scope is deliberately small: they exercise preference replacement and origin separation. They do not implement session revocation, validate an identity provider, or claim that removing a browser cookie invalidates a server-side record. The marker-based assessment laboratory separately tests the stated placement and request boundaries. Internet-Draft