Last updated: March 15, 2026

HSTS supercookies exploit the browser’s HSTS preload list (which persists locally) to encode tracking identifiers: a site sends HSTS headers that instruct the browser to remember dozens of related domains, and the pattern of which domains are recorded in HSTS creates a unique fingerprint. This persists across private browsing, cookie deletion, and even browser resets. Mitigation - regularly clear your HSTS cache (though most modern browsers reset it in private mode), use privacy extensions that block HSTS state storage, or switch to Tor Browser which isolates HSTS per-session.

Table of Contents

How HSTS Supercookies Work

HSTS works through a header that servers send to browsers:

Strict-Transport-Security - max-age=31536000; includeSubDomains

When a browser receives this header, it records the domain in its HSTS preload list for the specified duration. The critical privacy implication: browsers store this information persistently, and the presence or absence of HSTS for a domain can encode binary information.

Encoding Data as HSTS State

Attackers can exploit this by controlling multiple subdomains, each sending different HSTS policies. A tracker sets HSTS on some subdomains while leaving others unset. When the user visits an identifier page, the tracker queries these subdomains and observes whether the browser attempts HTTPS connections (indicating HSTS is active) or falls back to HTTP.

This creates a binary encoding system:

With enough subdomains, you can encode unique identifiers. A 32-subdomain setup provides over 4 billion unique combinations, enough to track users indefinitely without traditional cookies.

Practical Example

Consider a tracker controlling these subdomains:

track-0.example.com
track-1.example.com
track-2.example.com
...
track-31.example.com

The tracker encodes a 32-bit user ID by setting HSTS headers selectively:

// Server-side code (Node.js) demonstrating the encoding
function setHSTSForUserId(userId) {
  const subdomains = [];
  for (let i = 0; i < 32; i++) {
    const bit = (userId >> i) & 1;
    if (bit === 1) {
      subdomains.push(`Strict-Transport-Security - max-age=31536000; includeSubDomains`);
    }
  }
  return subdomains;
}

// On first visit, set HSTS based on user ID
app.get('/init', (req, res) => {
  const userId = generateUniqueId(); // 32-bit identifier
  res.set('Strict-Transport-Security', `max-age=31536000; includeSubDomains`);
  // Redirect through each subdomain to set HSTS state
  res.redirect(`/setup?id=${userId}`);
});

The browser then remembers these HSTS settings for up to one year.

Detecting HSTS Supercookies

Power users can inspect HSTS state in their browsers:

Chrome - Navigate to chrome://net-internals/#hsts

Firefox - Type about:networking in the address bar and check the HSTS section

Command-line verification:

Query HSTS state using Chrome's net-internals
echo "example.com" | grep -q "HSTS" && echo "HSTS enabled" || echo "No HSTS"

Mitigation Strategies

Several approaches help prevent HSTS supercookie tracking:

  1. Clear HSTS State

Regularly clear HSTS data through browser settings. In Chrome, you can delete HSTS domains via chrome://net-internals/#hsts by typing a domain and checking its status, then using the “Delete domain security policies” option.

  1. Use Firefox’s Enhanced Tracking Protection

Firefox blocks known supercookie tracking by default. Enable strict tracking protection in settings.

  1. Browser Extensions

Extensions like “Forget Me Not” or “Privacy Badger” attempt to neutralize supercookie vectors.

  1. Network-Level Blocking

Configure Pi-hole or similar DNS-level blockers to prevent connections to known tracking subdomains.

The Broader Implications

HSTS supercookies represent a fundamental tension in web security. The same mechanism that protects users from protocol downgrade attacks enables fingerprinting that bypasses traditional privacy controls. Unlike cookies, HSTS state persists through:

This makes HSTS supercookies particularly difficult to combat. Security researchers continue to propose solutions, including randomizing HSTS behavior or requiring explicit user consent before HSTS policies are applied.

Testing Your Browser

You can verify your browser’s vulnerability using online testing tools:

Using curl to check HSTS headers (manual verification)
curl -I https://example.com 2>/dev/null | grep -i "Strict-Transport-Security"

If you see the HSTS header, your browser will remember this domain for the specified duration.

HSTS Preload Lists and Long-Term Persistence

The HSTS preload list takes supercookie persistence to another level. Major browsers ship with a compiled list of domains that should always use HTTPS, this list is hardcoded into browser binaries and cannot be easily cleared by users. While the preload list itself isn’t designed for tracking, it demonstrates how deeply embedded HTTP redirection can become.

For developers, understanding preload implications matters:

// Check if a domain is on Chrome's HSTS preload list
// This cannot be cleared by users
const preloadDomains = [
  'google.com', 'facebook.com', 'twitter.com',
  // ... thousands of other domains
];

function isPreloaded(domain) {
  return preloadDomains.includes(domain.toLowerCase());
}

Preloaded domains automatically enforce HTTPS for one year minimum, creating persistent connection behavior that cannot be overridden without browser updates.

Developer Considerations

Web developers should understand both the security benefits and privacy concerns of HSTS:

When implementing HSTS in your applications, consider using shorter max-age values during development:

Nginx configuration for HSTS
add_header Strict-Transport-Security "max-age=3600; includeSubDomains" always;
Development - short max-age
Production - max-age=31536000; includeSubDomains; preload

Practical Supercookie Detection

Detect if a website is attempting to use HSTS for tracking:

// Monitor for multiple HSTS subdomains being accessed
// This is suspicious if unrelated to legitimate subdomain usage

// Check HSTS state progression
const hstsDomains = [
  'track-0.example.com',
  'track-1.example.com',
  'track-2.example.com'
];

// In browser console (limited access due to SOP)
// Legitimate use: cdn.example.com, api.example.com
// Suspicious - dozens of track-*.example.com subdomains

// Use Firefox > about:networking to inspect HSTS entries
// Report suspicious patterns to site authors

Most tracker implementations use hundreds of tracking domains. If you observe unusual HSTS domain patterns during security research, document and report them.

Browser-Specific HSTS Clearing

Different browsers store HSTS state differently:

Chrome/Edge:

Navigate to - chrome://net-internals/#hsts
Type domain name in "Delete domain security policies" field
Click "Delete" to remove single domain
For full reset - Clear browsing data > All time > Cookies > Clear data

Firefox:

HSTS data stored in SiteSecurityServiceState.txt
Location - ~/.mozilla/firefox/[profile]/
Delete file to clear all HSTS state
Or navigate to - about:networking > View HSTS state (limited interface)

Safari:

HSTS state stored in ~/Library/Safari/LocalStorage/
Clear via - Settings > Privacy > Manage Website Data > Remove All
Less granular than Chrome/Firefox

Clear HSTS state every 3-6 months when you prioritize privacy. This prevents long-term supercookie persistence but may break legitimate HSTS protections temporarily.

HSTS Supercookie vs. Traditional Cookie Tracking

Understanding the key differences helps identify supercookie attacks:

Aspect Traditional Cookie HSTS Supercookie
Storage Mechanism Browser cookie storage HSTS preload list
Persistence Expires per max-age Expires per HSTS max-age
Survives Private Browsing No Yes
Survives Cookie Deletion No Yes
Survives Browser Resets No Sometimes
User Awareness Visible in settings Hidden in security settings
Encoded Information Arbitrary data Binary (domain present/absent)
Detection Difficulty Easy (visible) Hard (requires technical knowledge)

HSTS supercookies are significantly more persistent and harder to detect than traditional cookies.

Real-World Tracking Implementation Analysis

Security researchers have documented actual HSTS supercookie tracking:

In 2017, researchers at Princeton University demonstrated tracking using HSTS. A tracker encoded a unique identifier by selectively setting HSTS on dozens of subdomains. When a user visited different websites, the tracker queried these subdomains and observed which had HSTS enabled, reconstructing the user’s unique identifier.

The technique requires:

  1. Control of many subdomains under the same registrar domain
  2. Access to set HSTS headers (server-side control)
  3. A mechanism to query HSTS state across different websites
  4. Cross-site request timing to infer which subdomains have HSTS

This attack vector persists because browsers generally don’t expose HSTS state to websites, the browser keeps it internal. However, timing-based side channels and other indirect methods can leak HSTS information.

Mitigation for Site Administrators

If you operate a website and want to prevent HSTS supercookie abuse:

Implementation approach
Only set HSTS on your main domain, not tracking subdomains
Avoid creating hundreds of subdomains with HSTS headers
Monitor for unusual HSTS domain patterns

Example safe HSTS config
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Avoid:
- Creating track-0.example.com through track-1000.example.com
- Setting HSTS on every subdomain
- Using subdomains as tracking vectors

Legitimate HSTS use should cover your main domain and necessary subdomains (api, cdn, mail, etc.), typically under 20 total domains.

Future Browser Protections

Modern browsers are implementing mitigations:

Chrome 125+ - Discussions about randomizing HSTS behavior or requiring explicit user consent for supercookie-like techniques.

Firefox - Privacy Badger and similar extensions partially mitigate by clearing HSTS state frequently.

Safari - iCloud Private Relay and cookie isolation provide defense-in-depth against tracking.

The fundamental tension remains - HSTS is necessary for security, but its persistent nature enables tracking. Until browsers redesign HSTS with privacy-first principles, users must actively clear HSTS state and use privacy extensions.

Frequently Asked Questions

Who is this article written for?

This article is written for developers, technical professionals, and power users who want practical guidance. Whether you are evaluating options or implementing a solution, the information here focuses on real-world applicability rather than theoretical overviews.

How current is the information in this article?

We update articles regularly to reflect the latest changes. However, tools and platforms evolve quickly. Always verify specific feature availability and pricing directly on the official website before making purchasing decisions.

Are there free alternatives available?

Free alternatives exist for most tool categories, though they typically come with limitations on features, usage volume, or support. Open-source options can fill some gaps if you are willing to handle setup and maintenance yourself. Evaluate whether the time savings from a paid tool justify the cost for your situation.

Can I trust these tools with sensitive data?

Review each tool’s privacy policy, data handling practices, and security certifications before using it with sensitive data. Look for SOC 2 compliance, encryption in transit and at rest, and clear data retention policies. Enterprise tiers often include stronger privacy guarantees.

What is the learning curve like?

Most tools discussed here can be used productively within a few hours. Mastering advanced features takes 1-2 weeks of regular use. Focus on the 20% of features that cover 80% of your needs first, then explore advanced capabilities as specific needs arise.

Related Articles

Built by theluckystrike. More at zovo.one