Autofill into hidden fields can harvest data and must be scoped

What it is

Browsers sometimes write stored names, addresses, and payment data into inputs the user cannot see. The page then submits those values with the form. Scoping means: do not put name, address, or payment semantics that autofill will recognize on hidden, zero-size, off-screen, or opacity:0 controls. Non-visible fields either drop fill semantics or do not sit in a form that will be submitted. This is defensive scope control, not a recipe for building such pages. Wrong names on visible boxes, and two sources racing, are different problems.

Why it happens

Autofill heuristics look at field semantics, not at whether a person can see the control. An invisible control that still carries address or payment tokens may be written with values the user never agreed to hand to this form. Checking happens on visible boxes; hidden values skip the check, and an extra profile leaves the browser. A second layer is that visibility itself changes. A collapse, a conditional reveal, display:none later opened by script—the field is hidden on the fill beat and shown on the submit beat, or the reverse. The scope rule has to follow “is this visible and editable on this beat,” not “does the node exist in the DOM.” The product’s own hidden fields (CSRF token, item id) must not carry name/address tokens; if they do, they become another exit.

Studying it

List every input from the accessibility tree and computed style, mark those that are not visible but still carry fill semantics, and watch whether a browser profile is written into them when a visible field is focused.

Independent variables: method of invisibility (hidden / zero size / off-screen / collapsed), whether a standard autocomplete token is present, whether submit includes those nodes. Dependent variables: whether invisible nodes contain address or payment fragments from the profile, whether the user knew, whether the payload contains personal data the visible form never showed.

Do not run attack drills beyond write-tests on real user profiles; use a dedicated test profile. Review against payload and visibility lists, not against “we are not malicious.”

Where it stops holding

Password managers may fill fields that are visually hidden but exposed to assistive technology; that is not the same class as “invisible to everyone and still submitted.” A legitimate honeypot for bots should use names autofill will not recognize as personal data, be discarded server-side, and never store real user data. Native autofill APIs have their own visibility rules; Web hidden does not transfer. Fields temporarily hidden in debugging are easily shipped; a release check must be harder than a code review.

Applying it

• List every input that will be submitted. For those not visible or not editable to the user, strip name/address/payment autocomplete tokens and do not use name values heuristics treat as those types.
• Conditional fields carry fill semantics only after they are actually expanded and editable; while collapsed they count as not visible.
• Scan the payload before submit: personal data the visible form never showed is a failure.
• Verify with a test profile holding address and payment data: fill only visible items; hidden inputs in developer tools must stay empty. Make a zero-height input with cc-number as a control a release check must block. Submit a collapsed address group without expanding it; the payload must not contain the profile address.

Related

• Within the group: H1.13.1 Browser autofill and in-app prefill have different sources and must be handled apart · H1.13.2 Nonstandard field names make autofill land in the wrong fields · H1.13.4 Autofill results must remain manually overridable
• Adjacent: O1.01 Privacy by design · H1.14 Conditional fields and dynamic reveal · O3.17 On-screen exposure of sensitive information
• Search terms: autofill · hidden input · autocomplete