Inferensys

Glossary

Supercookie Detection

The identification of persistent tracking mechanisms that abuse browser features like HTTP Strict Transport Security flags or favicon caches to respawn cleared identifiers, often used to bypass user privacy controls.
Security analyst reviewing fraud detection AI on multiple screens, alert dashboards visible, dark mode monitoring setup.
PERSISTENT TRACKING IDENTIFICATION

What is Supercookie Detection?

Supercookie detection identifies persistent tracking mechanisms that abuse browser features to respawn cleared identifiers, bypassing user privacy controls.

Supercookie detection is the technical process of identifying and neutralizing tracking mechanisms that exploit browser features—such as HTTP Strict Transport Security (HSTS) flags, favicon caches, or ETag headers—to store identifiers that persist even after users clear standard cookies. Unlike conventional HTTP cookies, these supercookies respawn from redundant storage locations, making them resistant to deletion and a significant privacy concern.

Detection techniques involve analyzing browser storage anomalies, inspecting cache integrity, and monitoring for unauthorized identifier synchronization across isolated storage APIs. Security architects deploy supercookie detection within behavioral biometrics frameworks to distinguish between legitimate session persistence and privacy-invasive tracking, ensuring compliance with regulations like GDPR while maintaining robust fraud detection capabilities.

PERSISTENT TRACKING IDENTIFICATION

Core Characteristics of Supercookie Detection

Supercookie detection involves identifying and neutralizing tracking mechanisms that abuse browser features to persist identifiers beyond user deletion. These techniques exploit protocol-level artifacts to bypass conventional privacy controls.

01

HSTS Flag Abuse Detection

Identifies tracking that exploits HTTP Strict Transport Security flags to store persistent identifiers. Attackers encode values by toggling HSTS policies across subdomains, creating a bit-encoded fingerprint that survives cache clearing.

  • Monitors HSTS cache state across subdomain requests
  • Detects anomalous 307 Internal Redirect patterns
  • Flags domains using HSTS as a storage channel
  • Cross-references with known tracker domain lists
32-bit
Max Identifier Capacity
Subdomain
Storage Mechanism
02

Favicon Cache Fingerprinting

Detects the abuse of favicon caches to store persistent identifiers. Trackers force browsers to cache unique favicon combinations across subdomains, creating a combinatorial identifier that persists even after cookies are cleared.

  • Analyzes favicon request patterns for enumeration behavior
  • Detects subdomain chains serving unique favicon.ico files
  • Monitors cache probing via onload/onerror event timing
  • Flags domains with excessive favicon subdomain variations
Browser Cache
Persistence Vector
Timing Side-Channel
Detection Method
03

ETag Header Tracking

Identifies the misuse of HTTP ETag headers as persistent storage. ETags are cache validation tokens that browsers store indefinitely; trackers set unique ETag values that are echoed back on subsequent requests, functioning as a respawnable identifier.

  • Inspects ETag values for encoded user identifiers
  • Correlates ETag consistency across cleared sessions
  • Detects If-None-Match header fingerprinting patterns
  • Flags servers setting ETags without Cache-Control headers
HTTP/1.1
Protocol Exploited
Conditional GET
Respawn Mechanism
04

TLS Session Resumption Tracking

Detects tracking via TLS session IDs and session tickets. These cryptographic tokens persist across browser restarts and can encode identifiers that survive all user clearing actions, operating below the HTTP layer.

  • Monitors TLS handshake for static session ID reuse
  • Detects session ticket rotation patterns indicating encoding
  • Analyzes Server Name Indication (SNI) field consistency
  • Flags connections with abnormally persistent session parameters
Transport Layer
OSI Layer Exploited
Session Ticket
Primary Vector
05

Storage API Enumeration Detection

Identifies tracking that probes browser storage APIs to reconstruct identifiers. Trackers test LocalStorage, IndexedDB, Service Worker caches, and other isolated storage mechanisms to find residual data after clearing attempts.

  • Detects rapid sequential reads across storage APIs
  • Monitors for storage quota probing patterns
  • Flags cross-origin storage access attempts
  • Identifies Service Worker registration as persistence vector
5+ APIs
Storage Vectors Probed
Cross-Origin
Reconstruction Method
06

Browser Fingerprint Correlation

Links supercookie identifiers to browser fingerprinting signals for respawning. When a user clears cookies, trackers match the recreated fingerprint to a previously stored supercookie value, restoring the identifier.

  • Correlates canvas fingerprint with HSTS snapshot state
  • Detects fingerprint-to-supercookie binding events
  • Monitors for identifier respawning after clearing events
  • Flags domains combining multiple persistence techniques
Multi-Vector
Attack Complexity
Respawn
Primary Goal
SUPERCOOKIE DETECTION

Frequently Asked Questions

Clear, technical answers to the most common questions about identifying and mitigating persistent browser tracking mechanisms that bypass user privacy controls.

A supercookie is a persistent tracking identifier stored outside the browser's standard cookie storage mechanisms, making it resistant to user deletion. Unlike standard HTTP cookies, which are domain-specific, easily cleared, and regulated by browser privacy controls, supercookies exploit browser features to respawn identifiers even after a user explicitly clears their cache and cookies. They are not technically cookies at all—they are identifiers injected into HTTP Strict Transport Security (HSTS) flags, favicon caches, ETag headers, or TLS session IDs. The critical distinction is persistence and stealth: a standard cookie respects a user's deletion intent, while a supercookie actively circumvents it by reconstructing the identifier from immutable or semi-persistent browser storage locations.

PERSISTENT TRACKING MECHANISMS

Real-World Supercookie Detection Scenarios

Explore the technical scenarios where supercookies are deployed to bypass user privacy controls, and the forensic methods used to detect these persistent, respawning identifiers.

01

HSTS Flag Abuse Detection

Detecting the abuse of HTTP Strict Transport Security (HSTS) flags to create a persistent identifier. Attackers encode a unique value by setting HSTS policies across a range of subdomains (e.g., bit0.example.com, bit1.example.com).

  • Mechanism: The browser stores a binary state (HSTS on/off) for each subdomain.
  • Detection: Forensic analysis of HSTS cache entries and monitoring for requests to a large number of non-existent subdomains on a single apex domain.
  • Indicator: A script that systematically probes 32+ subdomains to reconstruct a 32-bit user ID.
02

Favicon Cache Fingerprinting

Identifying the use of favicon caches as a storage vector. A tracking script forces the browser to request a unique set of favicons from distinct paths, encoding a user ID in the pattern of cached and uncached icons.

  • Mechanism: The script checks if a specific favicon is loaded from cache (fast) or fetched from the network (slow) using the onload event.
  • Detection: Monitoring for rapid, sequential requests to numerous unique favicon URLs on a single domain, especially those returning 404 or 301 status codes.
  • Red Flag: JavaScript that iterates through an array of paths like /id-0.ico, /id-1.ico and measures load timing.
03

ETag Header Respawning

Detecting the use of ETag HTTP response headers to respawn deleted cookies. The server sets a unique ETag value for a cached resource, which the browser sends back on subsequent requests via the If-None-Match header.

  • Mechanism: Even after a user clears cookies, the browser cache retains the ETag, allowing the server to reconstruct the identifier.
  • Detection: Inspecting network traffic for static resources with ETag values that appear to be high-entropy strings or Base64-encoded data, rather than standard content hashes.
  • Forensic Artifact: An ETag value that remains constant across multiple cache-clearing events.
04

TLS Session ID Resumption

Uncovering tracking via TLS Session Identifiers. A server can issue a unique Session ID during the TLS handshake, which the client caches and presents on the next connection to resume the session without a full handshake.

  • Mechanism: The Session ID acts as a persistent token stored outside of the browser's cookie jar.
  • Detection: Analyzing the ClientHello message in TLS traffic for Session IDs that persist across browser restarts and cookie deletions.
  • Key Distinction: Legitimate session resumption uses short-lived tickets; supercookies use long-lived, static identifiers.
05

Storage Quota Enumeration

Detecting tracking scripts that abuse the Storage API to estimate available disk space and generate a semi-unique fingerprint. By requesting a specific quota and measuring the granted bytes, a script can derive a device-specific value.

  • Mechanism: navigator.storage.estimate() returns quota and usage data that can vary slightly between browsers and devices.
  • Detection: Monitoring for scripts that call the Storage API without any legitimate file-saving or caching operation.
  • Context: This is often combined with other signals to create a high-entropy cross-browser fingerprint.
PERSISTENCE COMPARISON

Supercookies vs. Standard Tracking Mechanisms

A technical comparison of supercookie implementations against conventional browser tracking methods across key dimensions of persistence, user control, and detection difficulty.

FeatureStandard HTTP CookiesHSTS SupercookiesFavicon Supercookies

Storage Location

Browser cookie jar (document.cookie)

Browser HSTS cache

Browser favicon cache (disk or memory)

User Deletable via Browser Settings

Survives Incognito/Private Mode

Persistence After Clear History

Cross-Browser Tracking Capability

Requires JavaScript Execution

Detection Difficulty

Trivial

Moderate

High

Storage Capacity

4KB per cookie

1 bit per domain (visited or not)

~32 bits per domain (cache miss/hit pattern)

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.