Browser developers have invested significant effort into blocking traditional tracking cookies, but a more insidious category of trackers has emerged: supercookies. These persistent identifiers survive standard privacy protections and can reconstruct user profiles even after users clear their cookies, Incognito mode, or switch devices. This guide explains how supercookies work at a technical level and what developers and power users can do to detect and mitigate them.

What Are Supercookies?

The term “supercookie” refers to any tracking mechanism that mimics standard HTTP cookies but operates through alternative browser storage channels. Unlike regular cookies, which operate under strict browser security policies, supercookies exploit caching mechanisms, service workers, and other web platform features to persist beyond user deletion attempts.

Traditional cookies can be deleted by users or blocked entirely through browser settings. Supercookies circumvent these controls by storing identifiers in locations that users typically cannot access or even view. When users attempt to clear their browsing data, these identifiers often remain intact.

Storage Mechanisms Used by Supercookies

1. HTTP Strict Transport Security (HSTS) Pins

Websites can abuse HSTS policies to store tracking data. An HSTS preload list tells browsers to only connect to a domain over HTTPS. By using subdomain patterns, trackers can encode unique identifiers into which subdomains a browser has contacted, creating a persistent ID without using cookies at all.

2. Web Storage (localStorage and sessionStorage)

While technically accessible to users, localStorage provides larger storage capacity than cookies (up to 5MB versus 4KB). Trackers store persistent identifiers here, and clearing cookies does not affect this storage. Many users are unaware that localStorage persists across sessions.

// Checking for localStorage tracking data
const trackerIdentifiers = [];
for (let i = 0; i < localStorage.length; i++) {
  const key = localStorage.key(i);
  const value = localStorage.getItem(key);
  if (key.includes('uid') || key.includes('track') || value.length > 20) {
    trackerIdentifiers.push({ key, value });
  }
}
console.log('Potential trackers found:', trackerIdentifiers);

3. IndexedDB Storage

IndexedDB provides even larger storage capacity and supports complex data structures. Trackers use this to store detailed user profiles directly in the browser database.

// Enumerating IndexedDB databases (Chrome DevTools console)
indexedDB.databases().then(dbs => {
  dbs.forEach(db => {
    console.log(`Database: ${db.name}, Version: ${db.version}`);
  });
});

4. Service Workers and Cache API

Service workers intercept network requests and can store tracking identifiers in the Cache API. Unlike cookies, these persist through normal cache clearing and remain until explicitly removed.

// Checking cache storage for potential trackers
caches.keys().then(cacheNames => {
  cacheNames.forEach(cacheName => {
    caches.match(cacheName).then(response => {
      if (response) {
        console.log(`Cache: ${cacheName}`, response.url);
      }
    });
  });
});

5. HTTP ETag and Last-Modified Headers

Servers can embed unique identifiers in ETag values. Browsers cache these responses, and when users revisit, the browser sends the ETag back, revealing the same identifier. This technique works even in private browsing mode since caching is essential to browser functionality.

6. favicon.ico Tracking

A particularly clever technique uses the favicon to store tracking data. By serving different favicons based on a user’s unique identifier and using the browser’s favicon cache, trackers can identify users across sessions without any traditional cookie storage. The browser caches favicons aggressively, making this extremely persistent.

The Evercookie Approach

The most sophisticated supercookie implementations combine multiple storage mechanisms into a unified tracking system. The original “evercookie” library demonstrated this by storing the same identifier in cookies, localStorage, sessionStorage, IndexedDB, the Cache API, and various browser caching mechanisms. When a user deletes one storage channel, the identifier regenerates from another.

Modern tracking scripts use similar multi-channel approaches, ensuring that removing any single storage mechanism fails to eliminate the tracker.

Detection and Prevention

Browser Developer Tools

Modern browsers provide inspection capabilities for detecting supercookie storage:

Privacy-Focused Browsers

Several browsers actively block known supercookie techniques:

Blocking Code Example

You can prevent some supercookie techniques using Content Security Policy headers:

Content-Security-Policy: 
  default-src 'self'; 
  script-src 'self'; 
  img-src 'self' https:; 
  cache-control: no-store;
  HSTS: max-age=0;

Manual Removal

For localStorage and IndexedDB, users can run clearing scripts:

// Clear all localStorage
localStorage.clear();

// Clear all sessionStorage
sessionStorage.clear();

// Clear all caches (requires permission in some browsers)
caches.keys().then(names => {
  names.forEach(name => caches.delete(name));
});

// Clear all IndexedDB databases
indexedDB.databases().then(dbs => {
  dbs.forEach(db => {
    if (db.name) indexedDB.deleteDatabase(db.name);
  });
});

Implications for Developers

If you’re building web applications, understanding supercookie techniques helps you:

Implement proper consent mechanisms before using any storage. Use session-based storage when persistent tracking is not necessary, and verify that privacy-focused browsers handle your site correctly. Prevent attackers from using similar techniques for session fixation by auditing how your application reads and writes to browser storage.

The most effective defense is using a privacy-focused browser, auditing storage mechanisms periodically, and choosing implementation approaches that respect user control over browsing data.

Built by theluckystrike — More at zovo.one