Why Your Honeypot Catches Humans (Not Bots)

#security #webdev #html #tutorial

TL;DR: Password managers autofill hidden honeypot fields, causing legitimate users to fail bot detection. Five vendor-specific data-* attributes tell password managers to ignore these fields.

You implemented honeypot spam protection correctly: a hidden field that humans never see but bots fill out. Submissions with data in that field get rejected.

Then support tickets arrive: "I can't submit the form." The users aren't bots. They're using 1Password, LastPass, or Bitwarden, and their password manager dutifully filled every field on the page, including your invisible trap.

This is a documented problem. Craft CMS users report it. LocalWiki had to address it. Users on IsThereAnyDeal forums couldn't log in because Proton Pass triggered the honeypot.

The fix is straightforward: tell password managers to ignore the field.

The Attributes

Each password manager uses its own data attribute. There's no standard.

Provider	Attribute	Value	Evidence
1Password	`data-1p-ignore`	Boolean	1Password Developer Docs
LastPass	`data-lpignore`	`"true"`	LastPass Support
Bitwarden	`data-bwignore`	Boolean	Bitwarden Source Code
Dashlane	`data-form-type`	`"other"`	Dashlane SAWF Specification
Proton Pass	`data-protonpass-ignore`	Boolean	Proton Pass Source Code

NordPass has no documented developer attribute as of December 2025.

Boolean attributes like data-1p-ignore require no value. LastPass requires ="true" explicitly, or it may still autofill.

The Fix

Add all five attributes to your honeypot field:

<div class="form__alt" aria-hidden="true">
  <label for="website">Website</label>
  <input
    type="text"
    name="website"
    id="website"
    tabindex="-1"
    autocomplete="off"
    data-1p-ignore
    data-lpignore="true"
    data-bwignore
    data-form-type="other"
    data-protonpass-ignore
  />
</div>

<style>
  .form__alt {
    position: absolute;
    left: -9999px;
    width: 1px;
    height: 1px;
    overflow: hidden;
  }
</style>

The autocomplete="off" attribute is included for completeness, but most password managers ignore it. The vendor-specific attributes are what actually work.

Why So Many Attributes?

Password managers deliberately override autocomplete="off". Chrome's position is that users should control their credentials, not websites. Firefox agrees.

This is reasonable for login forms. It's problematic for honeypots, search bars, and other non-credential fields. The vendor-specific attributes exist because the standard attribute doesn't work.

Other Use Cases

Honeypots are the most common case, but these attributes help elsewhere:

Search inputs in admin panels: If your search field has name="name", password managers recognize the pattern and show autofill icons. Apache Superset added data-1p-ignore to fix this.

API key and token fields: Password managers autofill saved credentials into fields named "key" or "secret". HashiCorp Nomad encountered this in their token settings UI.

CMS content fields: Editors in WordPress or similar systems see password popups on unrelated text fields, requiring constant dismissal.

Accessibility Note

WCAG 2.2 Accessible Authentication requires that password managers work on login forms. Blocking autofill on actual credential fields violates accessibility guidelines.

These attributes should only be used on:

Honeypot fields
Search inputs
Non-credential configuration fields

Never on username or password fields for authentication.

Summary

Password managers fill every field they recognize, including hidden honeypots. The solution is five data attributes that tell each major password manager to skip specific fields.