When your Honeypot protection blocks real users using Autofill

Honeypot fields are a simple, user-friendly way to block spam bots without CAPTCHAs. But there’s a catch: modern browsers and password managers can accidentally trigger them, blocking legitimate users. Here’s how I discovered and fixed this issue.

When to Use Honeypot Fields

Honeypots work well for:

Contact forms – Block automated spam submissions
Registration forms – Prevent fake account creation
Login forms – Add a layer against credential stuffing bots
Password reset forms – Stop automated abuse of reset flows

The concept is straightforward: add a hidden form field that real users never see or fill. Bots, which blindly fill every field, will populate it – revealing themselves.

The Problem: Browser Autofill Gone Wrong

I had a honeypot field named website on the password reset form. It was hidden off-screen, invisible to users. Everything worked perfectly – until it didn’t.

Users started reporting that password resets weren’t working. They’d submit the form, see a success message, but their password never changed. The form appeared to work, but nothing happened on the backend.

After debugging, I discovered the culprit: Firefox’s password manager was auto-filling the honeypot field with the user’s email address.

The browser saw a field named “website” and, trying to be helpful, populated it with saved credential data. The bot protection then flagged these legitimate requests as spam and silently rejected them.

The silent rejection was intentional – I don’t want bots to know they’ve been detected. But it also meant real users had no idea why their password reset failed.

The Solution

Two changes fixed the issue:

1. Rename the field to something browsers won’t autofill

Changed the field name from website to fax_number. Browsers and password managers don’t typically auto-fill fax numbers – it’s an outdated field type that modern autofill systems ignore.

2. Use `autocomplete="new-password"`

This is the key fix. The autocomplete attribute tells browsers how to handle form fields. While autocomplete="off" is often ignored by modern browsers, autocomplete="new-password" is universally respected.

Browsers interpret this as “the user is creating a new password, don’t suggest existing ones” – which effectively disables autofill for that field.

The Fixed Implementation

<input
    type="text"
    name="fax_number"
    autocomplete="new-password"
    tabindex="-1"
    aria-hidden="true"
    style="position: absolute; left: -9999px;"
/>

Key attributes:

name="fax_number" – Unlikely to trigger autofill
autocomplete="new-password" – Explicitly prevents autofill
tabindex="-1" – Users can’t tab into it
aria-hidden="true" – Screen readers ignore it
style="position: absolute; left: -9999px;" – Visually hidden but still in DOM

Why This Doesn’t Weaken Bot Protection

You might worry: “If I add special attributes, won’t sophisticated bots learn to skip these fields?”

Not really. Here’s why:

Bots don’t run browser autofill – They fill fields programmatically, ignoring autocomplete attributes entirely
The field is hidden by CSS, not by attributes – Bots see all fields regardless of styling
Most spam bots are simple – They fill every visible field; they don’t analyze autofill attributes

The autocomplete attribute only affects browser behavior, not bot behavior. Your honeypot remains effective against automated submissions.

Key Takeaways

Avoid common field names like website, url, email2, or phone for honeypots
Always add autocomplete="new-password" to honeypot fields
Test your forms with browser autofill enabled
If honeypots silently reject requests, add logging to detect false positives