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.
Why deterministic ordering turns into a cross-origin leak
Browser APIs become fingerprinting surfaces when their output is stable enough to be compared across sites. The problem is not whether the API reveals a cookie or explicit identifier. If the same running process emits the same ordering to unrelated origins, that ordering can act as a shared signal that links visits, tabs, or sessions that should have remained separate.
That breaks a core browser assumption: that cross-origin data should not become a reusable correlator by accident. Determinism is especially risky when the values themselves look harmless, because the output can still be distinctive when combined with timing, process affinity, or other page-level observations.
The practical issue is that ordering is often treated as presentation detail, but for an attacker it can be a stable measurement surface. Even when the content is canonicalized or stripped of obvious identifiers, the ordering can still preserve enough structure to make two observations match.
What gets lost when the browser does not randomize or normalize
When ordering is visible across origins, the browser loses one of its main privacy barriers: per-origin isolation of observable state. A site does not need direct access to storage APIs, network identifiers, or script-visible IDs if it can infer that two visits came from the same execution context by observing the same sequence or rank ordering.
This can matter for session correlation, coarse user tracking, and browser-state inference. The signal may not be uniquely identifying on its own, but it can still narrow the candidate set enough to make cross-site linkage practical when paired with other low-entropy features.
The browser therefore needs to treat deterministic output as sensitive metadata, not just as a convenience feature. If the API is exposed at all, its shape should be designed so that two different origins cannot rely on stable process-local ordering to compare notes about the same user.
How to break the linkage without breaking the API
The safest pattern is to make the output non-comparable across origins unless comparability is explicitly required by design. That usually means canonicalizing before exposure, adding controlled nondeterminism, or otherwise transforming the result so that unrelated sites cannot infer a stable ordering from the browser’s internal state.
For browser implementers, the key judgment is whether the API’s utility depends on preserving raw internal order. If not, normalize it before it leaves the browser. If some ordering must remain, scope it tightly to the origin or context that legitimately needs it and remove any global process-level stability that could be reused elsewhere.
For web security reviewers, the test is simple: ask whether the API’s output could be observed twice by two different origins and still line up. If the answer is yes, treat it as a privacy-relevant surface and not merely a benign convenience.
Risk and Threat Considerations
Deterministic ordering can create a stable cross-origin correlation channel even when traditional storage and identifier APIs are unavailable. That makes it attractive for tracking, because the signal may survive ordinary privacy boundaries and can be reused over time if the same process or execution path is observable again.
Failure mechanism: A browser API exposes a repeatable order that reflects shared internal state, allowing different origins to compare observations and infer that they are seeing the same underlying user or session.
Impact: Cross-site correlation becomes possible without explicit IDs, which weakens origin isolation and can support tracking, profiling, or session linkage across visits.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Deterministic cross-origin output is an information-flow problem. |
| SC-13 — Cryptographic Protection | Designing outputs to prevent correlation is a protection requirement for sensitive browser state. | |
| PT-2 — Privacy Impact and Risk Assessment | The issue is a privacy exposure that should be assessed before release. | |
| Recommendation — Enforce information-flow controls so cross-origin observers cannot reuse stable browser state. Apply protective transformations that prevent observable state from being reused as a correlator. Assess whether the API output can enable cross-origin correlation before shipping it. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Browser-side normalization or neutralization can be part of protecting sensitive observable output. |
| Recommendation — Use protective transformations that reduce the chance of cross-origin linkage. | ||
| OWASP ASVS | V14 — Data Protection | Stable ordering is a data-exposure pattern that can reveal sensitive state indirectly. |
| Recommendation — Prevent indirect exposure by ensuring exposed data cannot be repurposed for fingerprinting. | ||
Practitioner Guidance
What to verify: Check whether the exposed ordering is stable across origins, reloads, and sessions, and whether it changes when the underlying internal state is the same but the origin changes. If two unrelated sites can reproduce the same rank order, treat that as a privacy defect, not just a deterministic interface.
What good looks like: The browser either removes the ordering signal entirely, or the observable output is normalized so that cross-origin observers cannot compare notes on the same internal state. If an order must exist, it should be origin-scoped and incapable of serving as a reusable fingerprinting surface.
Practitioner takeaway: When an API exposes repeatable structure, the privacy question is not whether it leaks an identity field, but whether it leaves behind a stable enough pattern for unrelated sites to recognize the same browser instance.
Related resources from NHI Mgmt Group
- What breaks when browser APIs expose deterministic metadata across sessions?
- What breaks when legacy applications cannot expose access data through APIs?
- What breaks when browser-based controls are used to protect machine-to-machine APIs?
- What breaks when public APIs expose too much identity metadata?