Back to Blog
Fingerprint

WebAuthn Fingerprinting: How FIDO2 APIs Expose Your Identity

How WebAuthn and FIDO2 authenticator capabilities become fingerprint vectors, and techniques to control authentication signals.

Introduction

WebAuthn (Web Authentication) is a W3C standard that enables passwordless authentication using public-key cryptography. It allows users to sign in to websites using biometric sensors, security keys, or platform authenticators built into their devices. The API powers passkeys, FIDO2 security keys, and the biometric login prompts that have become increasingly common on modern websites.

WebAuthn is a significant improvement for web security, replacing passwords with phishing-resistant cryptographic credentials. However, the API also exposes information about the device's authentication capabilities. These capability signals vary by platform, hardware, and browser version, and they can be queried silently without user interaction or permission. This makes WebAuthn a subtle but effective fingerprinting vector that most users are completely unaware of.

As passkeys become the standard replacement for passwords, WebAuthn queries will become even more common across the web. Protecting your WebAuthn signals is an increasingly important aspect of comprehensive fingerprint protection.

Privacy Impact

WebAuthn capability fingerprinting is subtle but effective. The signals do not require user interaction or permission. A website can query authenticator availability silently, before any login flow begins, and use the responses to build a device profile. This happens in the background with no visible indication to the user.

The privacy concerns include:

  • Platform identification: Capability queries reveal whether a device has biometric hardware or security chips. Devices with Touch ID, Windows Hello, fingerprint sensors, and those without any biometric hardware all produce different responses. This immediately segments users into hardware categories and narrows their platform identity.

  • Browser version detection: Certain WebAuthn features were added in specific browser versions. The presence and behavior of these features reveal the browser's version range, even after User-Agent string reduction efforts have made the User-Agent header less informative.

  • Headless browser detection: Standard headless Chrome environments typically report that no platform authenticator is available, because there is no security hardware in a headless context. This is one of the signals used to identify automated environments, which matters for privacy research and automated testing workflows.

  • Feature support matrix: The combination of authenticator availability, conditional mediation support, and other feature support creates a matrix that varies by platform. Different operating systems and hardware configurations produce distinct feature combinations, adding to the overall fingerprint.

A 2023 study examining WebAuthn deployment across the Alexa top 50,000 sites found that over 20% of sites queried WebAuthn capabilities even when they did not offer WebAuthn-based login. This suggests that capability queries are being used for purposes beyond authentication, potentially including fingerprinting and environment profiling.

Why This Matters for Your Privacy

Silent Data Collection

WebAuthn capability queries are completely silent. There is no permission prompt, no notification badge, and no visual indicator of any kind. Any website can determine your device's authentication capabilities the moment you visit, before you interact with anything on the page. This silent collection is what makes WebAuthn fingerprinting particularly concerning.

Hardware Profiling

Your device's authentication capabilities are tied to its hardware. Whether you have a biometric sensor, what type of security hardware is available, and what authentication methods your device supports are all revealed through WebAuthn queries. This hardware profile is persistent: it does not change when you clear cookies, switch to incognito mode, or use a different browser profile.

The Passkey Future

The industry is moving rapidly toward passkeys as a password replacement. This means WebAuthn capability queries will become even more common across the web. What is currently an occasional fingerprinting signal will become a routine query on most websites, making WebAuthn protection increasingly essential for anyone who values their privacy.

Headless Environment Detection

For privacy researchers, automated testing engineers, and anyone running browser automation, WebAuthn signals present a specific challenge. Standard headless environments lack security hardware, producing capability responses that differ from normal desktop browsers. This difference can identify automated environments, affecting the validity of privacy research and the reliability of automated workflows.

Common Protection Approaches and Their Limitations

VPNs and Proxy Servers

VPNs have no effect on WebAuthn capability signals. Authenticator availability is a local hardware property that has nothing to do with network routing. Two devices behind the same VPN report entirely different WebAuthn capabilities based on their local hardware. VPNs protect your network identity, but they leave your hardware fingerprint fully exposed.

Incognito and Private Browsing

Private browsing modes do not alter WebAuthn capability responses. Platform authenticator availability is the same in incognito as in a normal window, because the API queries hardware capabilities, not stored data. Incognito mode was designed to prevent cookie and history persistence, not to modify hardware-level capability reporting.

Browser Extensions

Extensions face fundamental limitations with WebAuthn protection:

  • Detection surface: Overriding the capability query methods at the JavaScript level changes their internal properties and is detectable through inspection techniques.
  • Functional impact: Incorrectly reporting platform authenticator availability causes issues when a website attempts to initiate an authentication flow that relies on the reported capabilities. This can break login flows and passkey registration.
  • Scope limitations: Extensions cannot control how the browser handles credential creation and retrieval calls, which interact with the operating system's authenticator framework at a level below what extensions can reach.

Disabling WebAuthn

Disabling WebAuthn entirely (removing the API from the browser) is itself a strong signal. As passkeys become more widespread, the absence of WebAuthn support is increasingly rare in modern browsers and marks the environment as unusual. Removing WebAuthn may actually make you more identifiable, not less.

BotBrowser's Engine-Level Approach

BotBrowser controls WebAuthn capability signals at the browser engine level through its profile system. All authenticator-related queries return results consistent with the loaded profile's target platform. This is not a JavaScript override or browser extension. BotBrowser modifies the browser's internal authenticator capability reporting, so the native APIs themselves produce profile-consistent results.

Profile-Based Authenticator Configuration

chrome --bot-profile="/path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

The profile defines the complete WebAuthn capability set: platform authenticator availability, conditional mediation support, supported transport methods, algorithm support, and feature availability. All values are captured from real devices, ensuring internal consistency. Your WebAuthn fingerprint matches a specific, real device configuration.

Cross-Platform Consistency

Running a macOS profile on a Linux server demonstrates the power of engine-level control. Without BotBrowser, a Linux server reports no platform authenticator. With a macOS profile loaded, the capability queries report that a platform authenticator is available, consistent with a Mac that has biometric authentication configured.

This cross-platform alignment extends to all WebAuthn signals:

  • Platform authenticator availability matches the profile's operating system and hardware configuration
  • Conditional mediation support matches the profile's browser version
  • Transport type support matches the profile's platform
  • Feature availability matches the profile's authenticator capabilities

BotBrowser ensures that every WebAuthn signal tells the same story as the rest of your browser profile, creating a coherent and authentic identity.

Headed and Headless Consistency

BotBrowser maintains consistent WebAuthn behavior in both headed and headless modes. The profile's values are applied regardless of display mode, eliminating the common situation where headless browsers report different authenticator capabilities than headed ones.

# Headless mode with full WebAuthn signals
chrome --bot-profile="/path/to/profile.enc" \
       --headless \
       --user-data-dir="$(mktemp -d)"

Whether you are running BotBrowser on a desktop or a headless server, your WebAuthn signals are identical. This is essential for privacy research, automated testing, and any workflow that requires consistent fingerprint identity across different execution environments.

Complete Capability Responses

BotBrowser's profiles do not simply set boolean flags. They configure the full matrix of WebAuthn behaviors including supported cryptographic algorithms, transport availability and preference ordering, resident key and user verification handling, and feature support and response formats. All of these details match the profile's target platform and browser version, creating a comprehensive and authentic WebAuthn identity.

Configuration and Usage

Basic CLI Usage

WebAuthn protection is automatic when loading a profile:

chrome --bot-profile="/path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

Playwright Integration

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
    ],
    headless: true,
  });

  const context = await browser.newContext({ viewport: null });
  const page = await context.newPage();

  // Verify WebAuthn signals match the profile
  const webauthnInfo = await page.evaluate(async () => {
    const results = {};
    if (window.PublicKeyCredential) {
      results.available = true;
      results.platformAuth = await PublicKeyCredential
        .isUserVerifyingPlatformAuthenticatorAvailable();
      if (PublicKeyCredential.isConditionalMediationAvailable) {
        results.conditionalUI = await PublicKeyCredential
          .isConditionalMediationAvailable();
      } else {
        results.conditionalUI = 'not supported';
      }
    } else {
      results.available = false;
    }
    return results;
  });

  console.log('WebAuthn signals:', webauthnInfo);
  await browser.close();
})();

Puppeteer Integration

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('about:blank');

  // Confirm WebAuthn protection is active
  const authInfo = await page.evaluate(async () => ({
    publicKeyCredential: !!window.PublicKeyCredential,
    platformAuth: window.PublicKeyCredential
      ? await PublicKeyCredential
          .isUserVerifyingPlatformAuthenticatorAvailable()
      : false,
  }));

  console.log('Authenticator info:', authInfo);
  await browser.close();
})();

Combined with Full Profile

For comprehensive identity consistency, combine WebAuthn protection with other BotBrowser features:

chrome --bot-profile="/path/to/profile.enc" \
       --bot-noise-seed=42 \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-config-timezone="America/Los_Angeles" \
       --bot-config-locale="en-US" \
       --user-data-dir="$(mktemp -d)"

This configuration gives you a complete, coherent identity where every signal, from WebAuthn capabilities to timezone, locale, and network identity, tells a consistent story.

Verification

After launching BotBrowser with a profile, verify that your WebAuthn signals are properly protected:

  1. Platform authenticator availability returns a value consistent with the profile's platform. A macOS profile with biometric hardware should report availability, while a Linux desktop profile should typically report unavailability.

  2. Conditional mediation support matches the profile's browser version capabilities. This feature was introduced in specific browser versions, so the response should align with the profile's target version.

  3. Headless and headed consistency is maintained. Run the same queries in both modes and confirm identical results. This eliminates one of the most common detection vectors for automated environments.

  4. Cross-profile differentiation is present. Different platform profiles should produce different WebAuthn responses, demonstrating that the values come from the profile rather than the host system.

  5. Fingerprint testing tools show no inconsistencies between WebAuthn signals and other platform indicators. Your WebAuthn identity should align with your platform, User-Agent, and navigator properties.

You can use fingerprint testing websites or BotBrowser's built-in verification tools to confirm these signals are properly aligned.

Best Practices

  1. Use platform-appropriate profiles. A macOS profile should report biometric authenticator availability. A Linux desktop profile should typically report unavailability. BotBrowser profiles are captured from real devices, so this alignment is built in when you choose the right profile for your needs.

  2. Verify headless behavior. If running in headless mode, confirm that WebAuthn signals match the headed mode behavior for the same profile. This consistency is one of BotBrowser's key advantages for anyone running headless workflows.

  3. Consider the passkey ecosystem. As passkeys become more widespread, WebAuthn capability queries will become more common. Ensure your profiles include appropriate conditional mediation support for modern browser versions. Using current, up-to-date profiles is the best way to stay ahead of this trend.

  4. Align with other platform signals. WebAuthn availability should be consistent with navigator properties, User-Agent, and other OS-specific signals in the profile. BotBrowser profiles ensure this alignment automatically, but verification gives you confidence that everything is working correctly.

  5. Combine with comprehensive protection. WebAuthn is one of many fingerprinting vectors. For complete protection, use a full BotBrowser profile that covers all fingerprint surfaces, from WebAuthn to canvas, audio, WebGL, and beyond. See the profile management guide for details on selecting and managing profiles.

Frequently Asked Questions

Does WebAuthn fingerprinting work without user interaction?

Yes. The capability queries are passive queries that require no user interaction, no permissions, and produce no prompts. Any website can determine your device's authentication capabilities silently and instantly. This is why proactive protection through BotBrowser is essential.

Can websites detect that WebAuthn signals are controlled?

If control is applied at the JavaScript level (overriding the native methods), it can be detected through inspection techniques. BotBrowser applies control at the engine level, so the native methods themselves return the controlled values without any JavaScript modifications to detect. The protection is completely invisible to the website.

Does BotBrowser support actual WebAuthn authentication flows?

BotBrowser's WebAuthn protection focuses on capability signals, the passive queries that websites use for fingerprinting and environment profiling. Actual authentication flows (creating credentials, signing challenges) require real authenticator interaction, which is a separate concern from fingerprint protection. BotBrowser protects your fingerprint identity while leaving the authentication infrastructure intact.

How does this relate to passkeys?

Passkeys use the WebAuthn API. The capability signals controlled by BotBrowser (platform authenticator availability, conditional mediation support) are the same signals that passkey implementations query. Controlling these signals ensures consistent reporting regardless of the host environment. As passkeys become more common, this protection becomes more important.

Do WebAuthn signals differ between Chrome versions?

Yes. Certain features were introduced in specific Chrome versions. Older Chrome versions do not expose these features. BotBrowser profiles are versioned and include the appropriate WebAuthn feature set for the target browser version, ensuring your signals match a valid, real-world configuration.

What about navigator.credentials?

The navigator.credentials API is broader than WebAuthn, encompassing password credentials and federated credentials as well. BotBrowser profiles control the public-key credential specific capabilities that are relevant for fingerprinting. Password and federated credential management behavior is influenced by the profile and user data directory.

Does this protect against attestation-based fingerprinting?

Attestation is a feature of the credential creation flow where the authenticator provides a signed statement about its identity. BotBrowser's capability signal protection addresses passive fingerprinting, which is the primary tracking concern. Attestation-based identification occurs during active authentication flows and requires user interaction.

Can headless environments be identified through WebAuthn alone?

With standard headless Chrome, yes. The lack of a platform authenticator in headless mode produces a response that differs from normal desktop browsers. BotBrowser eliminates this by maintaining profile-consistent WebAuthn signals in both headed and headless modes, so your headless environment is indistinguishable from a regular desktop browser.

Summary

WebAuthn capability signals reveal platform, hardware, and browser version information that serves as a persistent fingerprinting vector. Platform authenticator availability, conditional mediation support, and the broader feature matrix vary by device and operating system, creating a distinctive signal that requires no user interaction. As passkeys become the standard for web authentication, these queries will only become more common. BotBrowser controls all WebAuthn signals at the engine level through its profile system, ensuring cross-platform and headed/headless consistency. Your WebAuthn identity is authentic, stable, and fully aligned with every other aspect of your browser fingerprint. For related protection, see navigator properties protection, automation detection prevention, and comprehensive profile management.

#webauthn#fido#fingerprinting#authentication#privacy#passkeys