Firefox IndexedDB ordering exposed a stable browser fingerprint

At a glance

What this is: Fingerprint identified a Firefox IndexedDB ordering bug that turned database listing order into a stable browser fingerprint across origins and privacy modes.

Why it matters: It matters because privacy controls can fail when an API leaks deterministic process state, weakening unlinkability for browsers and users that depend on isolation.

By the numbers:

• With 16 controlled names, the theoretical space is about 44 bits of fingerprint entropy.

Context

IndexedDB is a browser storage API, but its metadata should not leak stable process state. When an API returns deterministic ordering from internal implementation details, that output can become a fingerprint even if no explicit identifier is exposed. In this case, the privacy boundary failed because the signal was derived from browser runtime behaviour rather than from user-managed storage.

For identity and privacy teams, the important lesson is that unlinkability depends on more than cookie deletion or private mode labels. If a browser process retains a deterministic signal, separate sessions can still be correlated across origins and across supposedly isolated modes. That makes implementation review of browser APIs and privacy features a governance issue, not just a coding defect.

The starting position here is atypical for user expectations but typical of how fingerprinting bugs arise: an internal structure becomes externally observable, and the privacy model assumes it stays hidden.

Key questions

Q: What breaks when browser APIs expose deterministic ordering across origins?

A: They can become stable fingerprinting surfaces even when they do not expose cookies, localStorage, or explicit IDs. If unrelated sites can observe the same ordering from the same running process, they can correlate activity across origins and sessions. The fix is to canonicalize or otherwise neutralize the output before it leaves the browser.

Q: Why do private browsing modes still fail when process state survives?

A: Because the user believes the session ended when the window closed, but the browser process may still retain deterministic internal state. If that state can be observed through an API, the new session is not truly unlinkable. Privacy controls have to be evaluated at the process boundary, not only at the window boundary.

Q: How do security teams detect browser fingerprinting risks in APIs?

A: Look for deterministic output, stable ordering, repeatable timing, and behaviour that depends on hidden internal state rather than user-visible data. Those signals often create cross-context linkability even when the API appears harmless. A good test is whether two unrelated contexts can derive the same identifier from the same runtime.

Q: What should product teams change after finding a privacy side channel like this?

A: They should normalize the output, test reset flows against long-lived runtime state, and treat any process-scoped signal as a privacy defect. The goal is to remove observability of internal implementation details before users rely on a mode such as private browsing or identity reset.

Technical breakdown

How IndexedDB ordering leaked process state

IndexedDB.database() returns metadata, but Firefox exposed the order produced by internal storage structures rather than a neutral canonical list. That matters because ordering is itself data. When database names are mapped into process-scoped structures and later emitted without sorting, the iteration order reflects hash-table behaviour, insertion history, and other runtime details. A site can exploit that stable permutation as a browser-instance identifier even though it never reads a cookie or storage value directly.

Practical implication: privacy-sensitive APIs must canonicalize output before exposing metadata that can vary with runtime state.

Why private browsing and Tor identity resets failed

Private browsing and Tor Browser are designed to reduce linkability, but the bug lived below those features in Gecko's IndexedDB implementation. Because the mapping and resulting order were process-scoped, the signal persisted across unrelated origins, across private windows, and through Tor Browser's New Identity flow until the browser process ended. That means the privacy boundary depended on process lifetime, not on session semantics, which is a brittle assumption for unlinkability.

Practical implication: treat process-scoped state as privacy-sensitive and verify that reset features actually clear every observable identifier.

Why the fingerprint had enough entropy to matter

A fingerprint only matters if it is stable enough and unique enough to correlate sessions. Here, controlled database names produce a permutation space whose theoretical size grows factorially with the number of names, which gives the signal substantial distinguishing power. Even if internal hash behaviour reduces the reachable space somewhat, the remaining entropy is still high enough to separate realistic browser instances. That is why a seemingly harmless ordering quirk can become a cross-site tracking primitive.

Practical implication: assess API side channels by stability and entropy, not just by whether they expose explicit identifiers.

Threat narrative

Attacker objective: The attacker wants a stable browser-instance fingerprint that survives normal privacy boundaries and enables cross-origin tracking without cookies.

1. Entry occurs when a website creates a set of IndexedDB databases and calls indexedDB.databases() to read the returned ordering.
2. The browser leaks a deterministic permutation derived from process-scoped internal storage state rather than origin-scoped user data.
3. The website reuses the same ordering across origins and sessions within the same running browser process to link activity.
4. Impact is cross-site tracking and weakened unlinkability in private browsing and Tor Browser until a full restart resets the signal.

Breaches seen in the wild

• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Deterministic metadata is a privacy boundary failure, not a minor implementation quirk. When browser APIs leak stable ordering or other process-scoped detail, they create linkability without any obvious identifier. That shifts the problem from storage protection to runtime observability, which is a different governance challenge. Practitioners should treat any deterministic cross-session signal as fingerprint material until proven otherwise.

Privacy modes fail when the reset boundary is below the user-facing session boundary. Private browsing, Tor circuits, and similar controls can all be undermined if shared process state survives the action the user thinks ended the session. The control gap is not merely missing deletion, but incomplete reset semantics across browser internals. Teams designing privacy features should validate what survives process lifetime, not just what survives window closure.

Fingerprinting resistance needs output normalization, not just access restriction. If an API is legitimately useful to developers, the safer design is often to return canonical, non-sensitive output rather than to rely on obscurity. That principle fits browser privacy, digital identity, and anti-tracking design alike. Practitioners should look for places where ordering, timing, or enumeration can be normalized before exposure.

IndexedDB exposes a broader lesson about implementation-derived identity. Systems can generate highly stable signals from hash tables, allocation patterns, ordering, and other internals even when no explicit identifier exists. That is why privacy reviews should include side-channel thinking, not only data minimization. Security architects should assume internal state becomes identity the moment it is observable across contexts.

Process-lifetime identity is a useful named concept for this failure mode. It describes any identifier that persists for the life of a browser process rather than for a user session or origin. Once that state can be observed externally, isolation features lose much of their value. The practitioner conclusion is straightforward: eliminate process-lifetime observability before it becomes a tracking primitive.

What this signals

Process-lifetime identity: this failure mode shows how a browser can create a persistent identity signal without exposing a traditional account or cookie. For privacy-sensitive products, the important question is not only whether data is stored, but whether internal state can be observed in a stable way across contexts.

Browser privacy engineering now needs to treat API ordering, iteration, and enumeration as potential identity surfaces. If unrelated origins can derive the same runtime signal, unlinkability has already weakened even when storage isolation still appears intact.

For practitioners

• Canonicalize storage metadata output Sort or otherwise normalize IndexedDB metadata before returning it so internal ordering cannot reflect process-scoped state.
• Test privacy resets against process lifetime Verify that private browsing exits, identity resets, and similar controls eliminate observable signals even when the browser process stays alive.
• Review APIs for fingerprintable ordering Audit browser-facing APIs for deterministic ordering, timing, or enumeration behaviour that can be reused as a fingerprint across origins.
• Treat runtime state as identity material Classify process-scoped browser state as sensitive when it can be observed by unrelated sites, then require explicit review before release.

Key takeaways

• A browser privacy feature can fail even when it blocks conventional storage, if an API leaks stable process-scoped state through deterministic ordering.
• In this case, unrelated sites could derive the same identifier from IndexedDB metadata order, and the signal survived private browsing and Tor's New Identity within a running process.
• Canonicalizing API output is the key mitigation because it removes the entropy source that turns internal implementation details into a tracking primitive.

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-Lifetime Identifier: A process-lifetime identifier is a signal that remains stable for as long as a browser process keeps running, even if tabs, windows, or private sessions change. It becomes dangerous when web content can observe it and use it to correlate activity across contexts.
• Unlinkability: Unlinkability is the property that separate sessions, sites, or interactions cannot be reliably tied back to the same user or browser instance. In privacy engineering, it depends on both storage boundaries and the elimination of side channels that expose stable state.
• 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.

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 is designed for practitioners who need to connect identity governance to the broader security decisions their programmes depend on.