Privacy Tools Guide

Privacy Risks of Browser Autofill Explained

Browser autofill saves time but silently fills form fields — including invisible ones. Malicious or poorly-coded websites can harvest autofilled data without you ever seeing it. This guide explains each attack class, the browser’s actual behavior, and configuration decisions that reduce risk without disabling autofill entirely.

How Autofill Works Internally

When you load a page with a form, the browser:

  1. Parses form fields and their name, id, autocomplete, and type attributes
  2. Matches these attributes against stored credentials, addresses, and payment data
  3. Fills matched fields — including fields that are display:none, visibility:hidden, or off-screen

The critical detail: the browser fills fields before you submit the form, and it fills fields that match by attribute regardless of whether they’re visible.


Attack 1: Hidden Field Harvesting

A form contains visible fields for the user and hidden fields targeting high-value autofill categories:

<!-- What the user sees -->
<input type="email" name="newsletter_email" placeholder="Enter your email">

<!-- Hidden fields that autofill silently populates -->
<input type="text" name="name" autocomplete="name" style="display:none">
<input type="text" name="address" autocomplete="street-address" style="display:none">
<input type="text" name="cc-number" autocomplete="cc-number" style="display:none">
<input type="text" name="cc-exp" autocomplete="cc-exp" style="display:none">

When you click the email field and autofill triggers, the browser fills all matching hidden fields. On form submit, the server receives your credit card and address even though you only intended to give your email.

Which browsers are vulnerable:

Browser Fills hidden fields Fills off-screen fields
Chrome 120+ Yes (with user interaction on a field in the form) Yes
Firefox 120+ Only on user-interacted fields No
Safari 17+ More conservative; generally does not fill non-visible fields No
Brave Follows Chromium behavior Yes

Chrome’s protection (user must click a field in the form before autofill fires for that form) reduces but does not eliminate the risk.


Attack 2: CSS Off-Screen Positioning

Fields positioned far off-screen (negative left or top) are not hidden but are not visible. Some browsers treat these as visible:

<!-- Off-screen but not display:none -->
<input type="text" autocomplete="cc-number"
       style="position:absolute; left:-10000px; top:-10000px">

Attack 3: Timing Attack (JavaScript Harvest Before Submit)

Even on legitimate-looking forms, JavaScript can read autofilled values immediately after fill — without waiting for the user to click Submit:

// Attacker's script runs after page load
window.addEventListener('load', () => {
  setTimeout(() => {
    const cc = document.querySelector('[autocomplete="cc-number"]');
    if (cc && cc.value) {
      // Silently exfiltrate without user interaction
      navigator.sendBeacon('/collect', JSON.stringify({ cc: cc.value }));
    }
  }, 500);  // 500ms after page load — user likely triggered autofill
});

This attack requires the attacker to control JavaScript on the page (XSS, malicious third-party script, or a supply chain compromise).


Attack 4: Cross-Origin iFrame Autofill

Some browsers allow autofill in iframes from different origins under certain conditions. A page loads a checkout iframe from a payment processor, but a malicious script in the parent page reads filled values via postMessage or shared DOM access (same-origin only, but misconfigured CSP can enable this).

// Parent page attempting to read iframe fields (fails with proper same-origin policy)
// But if CSP is misconfigured and attacker injects into parent:
const iframe = document.querySelector('#payment-iframe');
const ccField = iframe.contentDocument.querySelector('[name="cc-number"]');

Modern browsers block cross-origin DOM access, but the threat is real when CSP is absent or weak.


Attack 5: Password Autofill on Login Forms

Browser password managers autofill login forms. Trackers exploit this for fingerprinting:

<!-- A login form the user never interacts with -->
<form style="position:absolute; left:-9999px">
  <input type="email" name="email">
  <input type="password" name="password">
</form>

When the password manager sees this form, it autofills it. A script reads the email address to create a persistent cross-site identifier without cookies. The user is tracked even in private browsing.

Browsers that protect against this: Firefox 77+ added a protection that only autofills passwords on user interaction. Safari does not autofill hidden or off-screen forms.


Browser-Specific Configuration

Chrome / Brave

Settings > Autofill and passwords

Passwords:
  - "Offer to save passwords": disable if using a dedicated password manager
  - Never save passwords for sensitive sites (banking)

Payment methods:
  - "Save and fill payment methods": DISABLE
  - "Allow sites to check if you have payment methods saved": DISABLE

Addresses and more:
  - "Save and fill addresses": DISABLE (highest risk category)

Firefox

about:preferences#privacy

Logins and Passwords:
  - "Ask to save logins and passwords for websites": disable if using Bitwarden/1Password
  - "Autofill logins and passwords": disable for maximum safety

Forms and Autofill:
  - "Autofill addresses": DISABLE
  - "Autofill credit cards": DISABLE

Safari

Settings > Autofill

Use AutoFill to fill in:
  - Saved usernames and passwords: OK (Safari is conservative about hidden fields)
  - Credit cards: DISABLE
  - Other forms: DISABLE
  - Contact info: DISABLE

Use a Dedicated Password Manager Instead

Browser-native autofill conflates three separate functions: passwords, payment cards, and addresses. A dedicated password manager gives you control over each:

# Bitwarden (self-hosted or cloud) — disable browser native autofill
# and use Bitwarden extension exclusively

# In Bitwarden extension settings:
# - Enable autofill on page load: OFF (fill only on keyboard shortcut or click)
# - Default URI match detection: Host (not domain-wide)
# - Auto-fill on copy: OFF

# In your browser: disable all native autofill (payments, addresses, passwords)
# Let Bitwarden handle passwords only — with the autofill popup, not silent fill

autocomplete Attribute as Defense (For Developers)

If you’re building forms, use autocomplete="off" for fields that should never be autofilled:

<!-- Prevent autofill on a specific field -->
<input type="text" name="promo_code" autocomplete="off">

<!-- Prevent autofill on entire form -->
<form autocomplete="off">
  ...
</form>

<!-- For password fields where you want autofill disabled (new password only) -->
<input type="password" name="new_password" autocomplete="new-password">

Note: autocomplete="off" is treated as a suggestion by browsers, not a hard requirement. Chrome ignores it for saved passwords. For absolute prevention of password autofill, use autocomplete="new-password" and a non-standard field name.


Defense Summary

Measure Protects Against Who Does It
Disable address/card autofill Hidden field harvesting User (browser settings)
Use password manager with explicit fill Timing attacks, fingerprinting User
autocomplete="off" on sensitive fields Some autofill exposure Developer
Content Security Policy (strict) XSS-based JS harvest Developer
Subresource Integrity on third-party scripts Supply chain script injection Developer
Firefox/Safari over Chrome Conservative autofill behavior User


Built by theluckystrike — More at zovo.one