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:
- Parses form fields and their
name,id,autocomplete, andtypeattributes - Matches these attributes against stored credentials, addresses, and payment data
- 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 |
Related Reading
- Audit Chrome Extensions Privacy Guide
- Password Manager Autofill Security Risks
- How to Use Zeek for Network Monitoring
Built by theluckystrike — More at zovo.one