Browser autofill is one of those conveniences that feels invisible until it becomes a liability. For developers and power users who value privacy, understanding how autofill works—and where it fails—is essential for building secure forms and protecting sensitive data.

How Browser Autofill Actually Works

Modern browsers store autofill data in several places. Chrome maintains a SQLite database at ~/Library/Application Support/Google/Chrome/Default/Web Data on macOS, containing tables for credit cards, addresses, and profile information. Firefox uses a JSON-based storage format encrypted with a master password if set, otherwise stored in plain text.

When you visit a form field, the browser matches the name, id, and autocomplete attributes against its stored profiles. The autocomplete specification defines standard values like name, email, tel, credit-card-number, and street-address. Here’s a typical form that triggers autofill:

<form>
  <label for="email">Email</label>
  <input type="email" id="email" name="email" autocomplete="email">
  
  <label for="full-name">Full Name</label>
  <input type="text" id="full-name" name="full-name" autocomplete="name">
  
  <label for="address">Street Address</label>
  <input type="text" id="address" name="address" autocomplete="street-address">
  
  <label for="phone">Phone</label>
  <input type="tel" id="phone" name="phone" autocomplete="tel">
</form>

The browser will automatically populate any matching fields when the user clicks into one of them, or when the page loads in some cases. This behavior is where privacy concerns emerge.

The Core Privacy Risks

Data Exposure Through Hidden Fields

One of the most significant risks involves hidden fields that scrape autofill data. A malicious website can include invisible form fields designed to trigger autofill for sensitive information the user never intended to share:

<!-- Visible fields user expects to fill -->
<input type="text" name="name" placeholder="Your name">

<!-- Hidden fields that still trigger autofill -->
<input type="text" name="hidden_email" style="display: none;" autocomplete="email">
<input type="text" name="hidden_phone" style="display: none;" autocomplete="tel">
<input type="text" name="hidden_credit_card" style="display: none;" autocomplete="cc-number">

When the user autofills the visible “name” field, the browser may also populate the hidden fields because they share the same origin. This technique has been documented in security research dating back to 2016, and while some browsers have added protections, the attack surface remains.

Cross-Site Data Leakage

Browsers typically allow autofill across different domains under certain conditions. When you save your address in Chrome, it becomes available on any website with matching autocomplete attributes. This means:

The fundamental issue is that autocomplete attributes are client-side hints, not server-side requirements. A site can request autocomplete="cc-number" even if it has no payment processing capability, and the browser will happily fill it.

Storage Vulnerabilities

Browser autofill data storage has multiple attack vectors:

Local Access: If someone gains physical or remote access to your machine, browser autofill data is often recoverable. On Windows, Chrome’s Web Data SQLite database can be opened with tools like DB Browser for SQLite. Without a master password (Firefox) or OS-level encryption, this data sits in relatively accessible files.

Extension Overreach: Browser extensions with broad permissions can read autofill data. Extensions you install for one purpose may have the capability to access form data across all websites you visit.

Memory Handling: After autofill populates a field, the data remains in DOM memory and can be accessed through JavaScript. While this is intended functionality for form processing, it also means any script running on the page can capture the autofilled values.

Security Implications for Developers

Building Safer Forms

If you’re developing forms that accept sensitive data, consider these patterns to protect users:

// Disable autofill for sensitive fields until user interaction
const sensitiveInput = document.getElementById('ssn');
sensitiveInput.autocomplete = 'off';

// Re-enable after user clicks into the field
sensitiveInput.addEventListener('focus', function() {
  this.autocomplete = 'on';
});

This approach prevents pre-loading of sensitive data while maintaining usability for users who intentionally want autofill.

Using Appropriate Autocomplete Values

The Web Authentication standard provides more specific autocomplete values. Use autocomplete="off" sparingly—it actually reduces security in some cases by preventing browsers from applying their security measures:

<!-- Good: Specific autocomplete for security-critical fields -->
<input type="password" autocomplete="current-password">
<input type="text" autocomplete="one-time-code">

<!-- Problematic: Completely disabling autocomplete -->
<input type="text" autocomplete="off">

Implementing Token-Based Security

For sensitive operations, consider implementing your own token system rather than relying on browser autofill:

// Instead of storing full credit card, use tokenized payment
async function processPayment(token) {
  const response = await fetch('/api/payment/process', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ token })
  });
  return response.json();
}

This shifts the sensitive data handling to payment processors who specialize in secure data handling, reducing your liability and exposure.

Mitigation Strategies for Power Users

Browser-Level Protections

Several browser settings can reduce autofill risks:

Extension Hygiene

Review your browser extensions regularly. Remove any extension that requests permission to “Read and modify all your data on all websites” unless you actively need that capability. Consider using extension managers like Extension Manager (Firefox) or similar tools to toggle extensions on and off.

Regular Data Clearing

Periodically clear your browser’s autofill data:

# Chrome (macOS)
rm ~/Library/Application\ Support/Google/Chrome/Default/Web\ Data

# Firefox - Use about:preferences to manage saved logins
# or command-line for profile-based management

Be aware that clearing autofill data affects your browser’s ability to automatically fill forms, so weigh the privacy benefit against the convenience loss.

The Passkey Alternative

Passkeys represent the most significant advancement in replacing autofill for authentication. By using WebAuthn/FIDO2 standards, passkeys eliminate the need to store and transmit passwords entirely:

// Register a passkey
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,
    rp: { name: "Your Service" },
    user: { id: userId, name: username },
    pubKeyCredParams: [
      { type: "public-key", alg: -7 }
    ]
  }
});

Passkeys never leave the user’s device, cannot be phished, and don’t rely on browser autofill mechanisms. For authentication use cases, this is the most privacy-respecting approach available.

Summary

Browser autofill convenience comes with real privacy and security costs. Hidden field attacks, cross-site data leakage, and storage vulnerabilities all represent vectors that developers and power users should understand. By building forms thoughtfully, using appropriate autocomplete attributes, and considering alternatives like passkeys, you can significantly reduce your exposure while maintaining usability.

For sensitive data handling, the best approach is often to avoid storing that data in the browser altogether—use dedicated password managers for credentials, tokenized payment systems for financial data, and consider passkeys as the long-term solution for authentication.

Built by theluckystrike — More at zovo.one