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.
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:
- Subdomain with HSTS enabled = 1
- Subdomain without HSTS = 0
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.
2. Use Firefox’s Enhanced Tracking Protection
Firefox blocks known supercookie tracking by default. Enable strict tracking protection in settings.
3. Browser Extensions
Extensions like “Forget Me Not” or “Privacy Badger” attempt to neutralize supercookie vectors.
4. 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:
- Private/incognito browsing sessions
- Cookie deletion
- Browser cache clearing
- Browser resets (until HSTS preload lists are cleared)
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:
- Security benefit: Prevents man-in-the-middle attacks and protocol downgrades
- Privacy concern: Creates a persistent state that trackers can exploit
- Best practice: Use HSTS, but be aware of how it interacts with tracking prevention tools
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:
- Control of many subdomains under the same registrar domain
- Access to set HSTS headers (server-side control)
- A mechanism to query HSTS state across different websites
- 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.
Related Articles
- Iphone Privacy Settings Complete Guide Turn Off All Tracking
- Macos Spotlight Privacy Settings Disable Tracking
- Encrypted DNS over HTTPS on Linux
- How to Configure DNS over HTTPS Inside a VPN Tunnel
- How to Set Up Encrypted DNS-over-HTTPS (DoH) on All Devices
Built by theluckystrike — More at zovo.one