Firefox IndexedDB ordering exposed a stable browser fingerprint

At a glance

What this is: Fingerprint identified a privacy flaw in Firefox-based browsers where IndexedDB result ordering could act as a stable, process-lifetime browser fingerprint.

Why it matters: It matters because privacy and identity teams should treat deterministic client-side metadata as linkability risk, especially where browser isolation and session reset controls are expected to prevent cross-context tracking.

By the numbers:

• The signal is not just stable, it also has high capacity: with 16 controlled database names, the theoretical space is about 44 bits.
• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Fingerprint's analysis of Firefox IndexedDB fingerprinting and browser linkability

Context

IndexedDB fingerprinting is a browser privacy issue that turns ordinary storage metadata into a linkability signal. When an API exposes deterministic ordering or stable process-level state, websites can correlate sessions without cookies, localStorage, or explicit cross-site identifiers. That matters because privacy controls fail when implementation details leak identity across contexts.

For identity and trust programmes, the lesson is broader than browsers: if a system exposes stable behaviour across sessions, it can become an unintended identifier. This intersects with digital identity governance, privacy engineering, and session isolation because users and regulators expect private modes and reset features to break continuity, not preserve it.

Key questions

Q: What breaks when browser APIs expose deterministic metadata across sessions?

A: Deterministic metadata can turn an otherwise harmless API into a stable identifier, allowing sites to correlate activity across origins and sessions. That breaks privacy assumptions even when cookies are blocked, because the browser runtime itself becomes the continuity mechanism. The right defence is to remove hidden entropy at the API boundary, not just to restrict obvious tracking storage.

Q: Why do private browsing and anonymity features still need runtime-state controls?

A: Private browsing and anonymity tools can only protect the state they actually reset. If process-level caches, mappings, or internal ordering survive, an application can still leak linkable signals after the user thinks the session ended. That means privacy design has to include lifecycle resets for runtime state, not only for visible session data.

Q: How do security teams know whether privacy controls are actually working?

A: Look for evidence that discovery, classification, DSR routing, and consent enforcement update when the environment changes. If privacy artifacts only refresh on calendar cadence or after manual chases, the programme is operating on stale assumptions. Working controls produce current inventory, traceable approvals, and audit-ready logs without depending on memory.

Q: Who is accountable when a privacy feature preserves linkability after reset?

A: Accountability sits with the product and platform owners who define reset semantics, the engineers who expose runtime state, and the reviewers who approve the API behaviour. Privacy claims must match actual state lifecycles, especially in browsers and identity-sensitive tools. If a reset feature does not break linkability, the control design is incomplete.

Technical breakdown

How IndexedDB ordering became a fingerprinting signal

IndexedDB is meant to be a local storage API, but its metadata can still leak identity if result ordering is deterministic. In this case, the order returned by indexedDB.databases() reflected internal storage structures rather than a neutral canonical sort. That made the output dependent on implementation details that stayed stable during a browser process, giving websites a reusable signal without needing direct access to cookies or shared state. Once a browser exposes process-scoped state through a public API, unrelated origins can derive the same identifier and use it for correlation.

Practical implication: review browser-exposed APIs for deterministic metadata leaks, not only for direct credential or cookie exposure.

Why private browsing and New Identity did not break linkability

Private browsing is designed to reduce persistence, but this flaw persisted because the identifier lived at the process level, not the tab or origin level. In Firefox Private Browsing mode, the mapping survived until the Firefox process exited. In Tor Browser, the same issue survived the New Identity action because that feature clears browsing state and rotates network identity, but it does not automatically rewrite every process-scoped implementation detail inside Gecko. That is a classic boundary mismatch between what users assume resets and what the underlying runtime actually preserves.

Practical implication: treat privacy reset features as incomplete unless the underlying runtime state is explicitly reinitialised.

Why canonical sorting removes the privacy leak

The defect exists because the API exposed entropy from internal storage layout. Canonicalising results, for example by sorting database names before returning them, removes that entropy and makes the output stable in a benign way instead of a fingerprinting way. Randomisation could also reduce linkability, but it complicates developer expectations and debugging. Sorting is simpler because it preserves utility while severing the connection between storage internals and observable output. In privacy engineering terms, the fix is to remove the identifier source, not just obscure it.

Practical implication: prefer deterministic canonicalisation over ad hoc randomisation when an API can leak hidden runtime state.

Threat narrative

Attacker objective: The attacker objective is to correlate browsing activity across origins and sessions without relying on cookies or explicit shared identifiers.

1. Entry occurs when a website creates multiple IndexedDB databases and queries the browser’s metadata API to observe ordering.
2. Escalation happens because the ordering reflects process-scoped internal state, allowing unrelated sites to derive the same stable identifier during the same browser runtime.
3. Impact is cross-origin and session linkability, including weakened private browsing isolation and Tor Browser New Identity boundaries.

NHI Mgmt Group analysis

Stable browser metadata is an identity problem, not just a privacy bug. When deterministic API behaviour can be observed cross-origin, the browser itself becomes an identifier source. That matters for digital identity governance because isolation controls are only effective if the runtime does not leak persistent signals. The practitioner conclusion is that privacy engineering and identity assurance now overlap at the API boundary.

Process-scoped state creates a verification trust gap. Users assume private browsing and reset features end linkability, but the underlying process may still preserve observable state. That is the same governance failure pattern seen whenever a control protects one layer while identity persists in another. Teams should treat runtime persistence as a first-class risk rather than a hidden implementation detail.

Canonicalisation is a governance control, not a cosmetic fix. Sorting or normalising exposed output removes entropy before it can become a tracking vector. This is a concrete example of designing APIs so that internal state cannot be repurposed as a fingerprint. The practitioner takeaway is to require privacy-preserving output design in review gates for browser, client, and SDK features.

Browser privacy features need lifecycle-aware reset semantics. A feature that clears cookies but leaves process-level identifiers intact does not actually end the identity session users think it ends. That is especially relevant where private browsing, anonymity tooling, or regulated user protections are involved. The field should demand explicit guarantees about what state survives a reset and what does not.

What this signals

Browser privacy failures often show up as identity failures later, because deterministic behaviour is still a form of persistent identity. The practical signal for security and privacy teams is to broaden review criteria so that APIs are assessed for linkability, not just for data access. The Ultimate Guide to NHIs is relevant here because the governance problem is the same: hidden state becomes an unmanaged identifier when visibility is weak.

Process-lifetime identity leakage: this is a useful shorthand for any feature that preserves continuity longer than users or policy expect. Once teams name the pattern, they can review reset semantics, process boundaries, and canonical output as part of release governance. That framing also aligns with browser privacy work and with the broader identity hygiene issue of uncontrolled persistence.

For identity programmes, this is a reminder that session boundaries are only as strong as the systems that enforce them. Where privacy modes, logout flows, or identity resets rely on internal state being cleared, teams need validation that links cannot be re-derived from metadata or ordering. The same governance logic applies to non-human identity lifecycle controls and to any system that must break continuity cleanly.

For practitioners

• Review APIs for deterministic output leaks Audit browser, client, and SDK APIs that return ordered metadata, hashes, or enumerations, and verify that implementation details cannot produce stable cross-session identifiers. Prioritise APIs used in privacy modes, anonymous browsing, or regulated environments.
• Test reset features against process-level persistence Validate whether private browsing, logout, or identity reset features actually clear process-scoped runtime state, not just cookies and storage. Use controlled tests to see whether identifiers survive until full application restart.
• Canonicalise exposed metadata before release Return sorted or otherwise normalised values when an API might reveal internal ordering. Remove the entropy source rather than relying on randomisation, because repeated calls and cross-origin observation can still expose stable behaviour.
• Map privacy bugs to identity assurance controls Include browser-side linkability and session continuity in your identity assurance reviews, especially where privacy modes support high-risk users or sensitive workflows. Treat deterministic metadata as an identity control failure, not a front-end nuisance.

Key takeaways

• Deterministic browser metadata can become a stable identifier even when no cookie or shared storage is involved.
• Private browsing and anonymity features fail when process-scoped state survives beyond the user-facing reset boundary.
• Canonicalising exposed output is the right control because it removes the hidden entropy that makes tracking possible.

Key terms

• Browser Fingerprinting: Browser fingerprinting is the practice of identifying or correlating users from device or browser characteristics that are stable enough to distinguish one session from another. It often exploits metadata, rendering behaviour, or API quirks rather than explicit identifiers, which makes it difficult to block with simple storage controls.
• Process-Scoped State: Process-scoped state is information that persists for the lifetime of an application process rather than for a tab, origin, or user session. In privacy-sensitive systems, this state can become an unintended identity signal if public APIs expose it directly or through deterministic behaviour.
• Canonicalisation: Canonicalisation is the practice of normalising output into a consistent, predictable form before it is exposed to callers. In privacy and security design, it helps remove hidden entropy, reduce ambiguity, and prevent internal implementation details from becoming externally observable signals.
• Private Browsing Isolation: Private browsing isolation is the expectation that activity in a private session will not be linkable to other sessions or to later browsing after the session ends. The control is only effective when all relevant state, including runtime artefacts, is cleared or prevented from persisting across the boundary.

What's in the full article

Fingerprint's full article covers the implementation detail this post intentionally leaves for the source:

• The exact IndexedDB ordering behaviour and why Gecko’s internal hash structures made it stable
• The proof-of-concept logic used to demonstrate cross-origin linkability in affected Firefox-based browsers
• The Firefox and Tor Browser remediation context, including the fix tracked in Mozilla Bug 2024220
• The reasoning behind canonical sorting as a privacy-preserving implementation change

👉 Fingerprint's full post covers the technical reproduction steps, root cause, and browser-specific privacy impact

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners connect persistence, visibility, and lifecycle discipline across identity and security programmes.