Autocomplete on Sensitive Form Fields

Autocomplete on sensitive form fields is a finding scanners raise when inputs like passwords, credit-card numbers, or security answers let the browser save and refill their values — the worry being that a cached value could be recovered on a shared or public computer. You check it by inspecting the autocomplete attribute on your form inputs, and you fix it by setting the correct semantic token per field, not by blanket-disabling autofill.

What is Autocomplete on Sensitive Form Fields?

Every text <input> in HTML carries an implicit or explicit autocomplete attribute that tells the browser whether it may remember and later refill that value. On ordinary fields this is a convenience; on sensitive ones — passwords, card numbers, national IDs, knowledge-based security answers — a scanner flags it because a saved value persists in the browser profile after the user walks away.

This maps to OWASP A05: Security Misconfiguration and is, in practice, a hardening and compliance-checkbox finding rather than a live exploit. It belongs to the same family of client-side hardening items as insecure cookies or a permissive referrer policy: real, worth getting right, but not an emergency.

Why it's a risk / how it's exploited

The classic scenario is a shared machine. Someone signs in on a library or kiosk computer, the browser offers to remember the card number or password, and the next person can trigger autofill and recover it. That risk is genuine but narrow.

Here is the honest, current picture: the old advice to slap autocomplete="off" on your login form is largely obsolete. Chrome, Firefox, and Safari deliberately ignore autocomplete="off" on username and password fields so that password managers keep working — and password managers meaningfully improve security by making strong, unique passwords practical. Disabling autofill fights the browser, breaks managers, and nudges users back toward weak, reused passwords. That's why this finding is rated low: the fix is almost never "turn autocomplete off," and doing so on credentials can make things worse.

How to detect it

Open the login, sign-up, payment, or profile page and inspect each input tag — via View Source, or DevTools → Elements → select the field and read its autocomplete attribute. From the command line you can pull the raw inputs:

curl -s https://example.com/login | grep -Eo '<input[^>]*>' | grep -i autocomplete

A field with no autocomplete token, or a bare autocomplete="on", is what gets flagged. A well-tagged field instead reads autocomplete="current-password" or autocomplete="cc-number" — a specific, semantic value. Note that a missing token on a password field is a labeling gap, not proof autofill is off, since browsers autofill credentials regardless.

Checking a few forms by hand is quick, but tokens drift out of sync across a signup flow, a checkout page, and a legacy profile form. A website vulnerability scan walks every form on the site and reports each sensitive field's autocomplete handling alongside the rest of your web application security posture.

How to fix it

Set the right semantic token per field instead of disabling autofill. This helps legitimate autofill and password managers do their job:

<!-- Login -->
<input type="password" name="password" autocomplete="current-password">

<!-- Sign-up / reset (also triggers strong-password suggestions) -->
<input type="password" name="new-password" autocomplete="new-password">

<!-- One-time passcode -->
<input type="text" inputmode="numeric" autocomplete="one-time-code">

<!-- Payment -->
<input autocomplete="cc-number">
<input autocomplete="cc-exp">

<!-- Genuinely sensitive one-off field, no manager benefit -->
<input type="text" name="security-answer" autocomplete="off">

Reserve autocomplete="off" for the last case: a value where caching adds risk and no password-manager benefit applies, such as a knowledge-based security answer. Some card-brand guidance still asks for off on the raw PAN field, so set it if a standard requires it — but understand the caveat that browsers may override off for anything they treat as a credential anyway. Do not disable password autocomplete site-wide.

FAQ

Should I put autocomplete="off" on my login password field? No. Modern browsers ignore it there to keep password managers functioning, and managers improve security overall. Use autocomplete="current-password" on login and new-password on sign-up and reset forms instead.

Isn't autofill on a shared computer a real risk? It's a modest one, limited to genuinely shared devices. The far bigger security lever is encouraging password managers, so the correct fix is using accurate tokens per field — not stripping autofill, which tends to weaken password hygiene.

---

Want to see which of your forms tag sensitive fields correctly? Run a free website vulnerability scan to check autocomplete handling and the rest of your web attack surface in one pass.