Autofill may insert mismatched history across origins, with privacy and error risk

What it is

Browser profiles are stored per person, not strictly per site (passwords are usually origin-scoped; addresses and phones are often wider). A home address saved on a shop can be offered on an unrelated form; a work email can land on a personal signup. Cross-origin mismatch is both a wrong-scene fill and an exposure of personal data to the current page's script and operator. Once a suggestion paints a full phone or ID number, shoulder surfers and page script can see it.

Why it happens

Addresses, phones, and names often live in the browser's “profile,” not in a per-origin vault. Heuristics that see similar slots will pop that profile on the current origin. A malicious or merely greedy page can receive fill in hidden fields (invisible inputs may still be filled, depending on mitigations). Password managers are strict on passwords and looser on identity fields. iframes and payment widgets blur origin: which document should get the card number depends on the browser's fill-scope policy. Choosing a suggestion authorizes the current page to read those strings; the UI rarely says so.

Studying it

Save different addresses on two unrelated origins, open a third-party form, and see whether the suggestion list leaks the other origin's data. Test hidden and opacity-zero fields for still being filled. Privacy audits should include whether page script can read values before versus after fill, and whether the suggestion dropdown exposes data in screenshots. Consent forms must state that realistic fake personal data will be used. Do not run cross-site tests on production accounts.

Where it stops holding

Strict per-origin password boxes will not put site A's password into site B; this claim mainly constrains identity and address. Enterprise browsers can lock profiles into a configuration, reducing leakage. Users who refuse to save on every origin get an empty list. A system “passwords only” fill mode can stop addresses from appearing. A legitimate payment iframe still needs to fill cards on an explicit payment origin; fear of cross-origin must not ban payment fill.

Applying it

• Do not rely on loose profile fill for high-sensitivity fields (government IDs, full PANs); use a payment widget or an explicit paste.
• Mark hidden fields autocomplete=off and avoid fillable types so they are not implicit receivers.
• Show masked suggestions (last four, city-level address) and write the full value only after the user confirms this origin.
• Verify with a clean profile: home address on origin A, work address on origin B, open a form on origin C, and list whether A/B appear as full plaintext. If they do, that is cross-site exposure.

Related

• Same group: C6.28.1 Autofill depends on field semantics; missing or wrong annotation fills the wrong content · C6.28.2 Autofilled content must stay editable before submit, not locked · C6.28.4 Autofill and validation timing must be coordinated so fill does not trip instant errors
• Adjacent: C6.15 Clipboard · C6.29 Dedicated password keyboards
• Search: cross-origin autofill · autofill privacy · hidden fields