New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 45 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Issue 132135: Chrome's Autofill feature circumvents anti-spam honeypot hidden form field techniques

Reported by, Jun 11 2012

Issue description

Chrome Version       : 19.0.1084.56 
URLs (if applicable) :
Other browsers tested:
     Safari 5: OK
  Firefox 4.x: OK
       IE 7/8/9: OK

What steps will reproduce the problem?
1.  Visit a website with an online form containing a hidden form field meant as a "honeypot" trap for spam bots.  Or, create a test form with a field hidden by wrapping it in a div using CSS to move the field out of human view (e.g. the div could have a style of:  margin-left:-9999em;position:absolute;).  Add logic to the form that causes the form submission to ignore any cases in which the "honey pot" trap field is filled with data (because only spam bots should be able to identify the hidden field and fill it out).

2.  Fill out the online form using Chrome's "Autofill" feature.

3.  The Autofill feature will insert bogus data into the hidden honey pot form field, even though the user had never stored any saved Autofill data for that field (because it's hidden, never seen by the end user). 

For more information on this issue, please see the following link:

What is the expected result?
Chrome should NOT autofill fields that the Chrome user had never saved in the autofill settings.  It should ONLY save the fields explicitly set by the user.

What happens instead?
Chrome's autofill feature will fill even hidden form fields with data when it should instead leave those fields blank.

Please provide any additional information below. Attach a screenshot if

Comment 1 by, Jun 12 2012

Labels: Feature-Autofill

Comment 2 by, Jun 12 2012

Labels: -Area-Undefined Area-UI OS-All Mstone-22
Status: Assigned
Chrome Autofill is specifically designed to help users quickly fill forms that they've never filled before.  However, we could probably do better at identifying form fields whose bounding boxes are completely off the screen, and not filling them.

Of course, a spam bot could employ the same logic that Chrome employs; so in the general case, you'd have to add autocomplete="off" to the field to prevent Chrome from filling it.

Comment 3 by, Aug 31 2012

Labels: -Mstone-22 Mstone-23 MovedFrom-22
Moving all non-blocking 22 issues to 23.

Comment 4 by, Oct 10 2012

Labels: -Mstone-23 MovedFrom-23 Mstone-24
Moving all non essential bugs to the next Milestone

Comment 5 by, Oct 29 2012

Labels: -Mstone-24 Mstone-25

Comment 6 by, Dec 20 2012

Labels: -Mstone-25 Mstone-26

Comment 7 by, Feb 6 2013

Labels: -Mstone-26 Mstone-27

Comment 8 by, Mar 10 2013

Project Member
Labels: -Area-UI -Feature-Autofill -Mstone-27 Cr-UI M-27 Cr-UI-Browser-Autofill

Comment 9 by, Mar 28 2013

Labels: -M-27 M-28

Comment 10 by, May 8 2013

Project Member
Labels: -M-28 MovedFrom-28
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.

Comment 11 by, Jul 18 2014

Owner: ----
Status: Available

Comment 12 by, Oct 22 2014

This bug seems to prevent transactions on our magento shop to work poperly. Hidden fields for transaction management are being filled with data overriding the technical steering data we need. This is really anoying.
So in our case, this should not be a minor seen defect!

Comment 13 by, Oct 22 2014


Comment 14 by, Oct 23 2014

ahachmann: mark them readonly?

Comment 15 Deleted

Comment 16 Deleted

Comment 17 by, Dec 26 2014

I strongly disagree that the onus should be placed on web developers to figure out a way around a clear flaw in Chrome.  By filling in form fields the end-user never sees, Chrome is essentially behaving like a spam bot.   How is that acceptable?

Chrome should only be completing the form fields the user had initially saved to autocomplete, not hidden fields.

Comment 18 by, Jan 20 2015

Well, I just ran into this problem when an angry customer came complaining their submissions were not going through. 3.5 years and this still has not been fixed? Adding a honeypot field is a very common trick these days, and with the amount of spam flowing this can hardly be a surprise.

I utterly dislike the only workaround to add 'autocomplete=off' to the field, because it *so very clearly* marks the honeypot as "don't fill me in". Even the most inexperienced spam bot author aware of this issue can take full advantage and it renders the honeypot next to useless.

Comment 19 by, May 13 2015

Probably the best thing that you can do, as a website developer who's running into this issue, is to label autofillable fields in your form with their autocomplete types, as described here: [1].  This has the helpful side-effect that fields which are not labeled with autocomplete types will never be filled by Chrome's Autofill feature.


Comment 20 by, Jun 21 2016

Project Member
Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Hotlist-Recharge-Cold label is added for tracking. Please re-triage this issue.

For more details visit - Your friendly Sheriffbot

Comment 21 by, Jan 5 2017

Components: Security
Labels: Team-Security-UX
Adding Team-Security-UX, since this is essentially the flipside of a UX problem.

Comment 22 by, Jan 6 2017

 Issue 678848  has been merged into this issue.

Comment 23 by, Jan 9 2017

 Issue 678985  has been merged into this issue.

Comment 24 by, Jan 9 2017

This issue also causes a long-standing bug in Jenkins where on one config page Chromium will helpfully fill in the user's saved login and password as the LDAP "managerDN" and "managerPasswordSecret" _in fields that are hidden by default_. Unsuspecting admins can break the config because their pewrsonal credentials will be used as ldap auth for the system.


Comment 25 by, Jan 9 2017


Comment 26 by, Jan 9 2017

Seems this has reached the "mainstream" media now as a potential phishing attack abuse:

Comment 27 by, Jan 17 2017

It's hard to believe that you guys don't care about hole leaking users personal data for 4,5 years!

In meantime, install the extension to see count/list of autocompleted fields:

Test it online:

From medium blogpost discussion:

Comment 28 by, Jan 18 2017

Status: Available (was: Untriaged)
I know that this is not a satisfying response, but we have several internal threads going on about how to best handle this, especially in light of the latest issues that have been discussed in the news. We apologize that we don't have a good solution yet, but we're working on it. We'll update once we have more to say.

Comment 29 by, Feb 16 2017

 Issue 688025  has been merged into this issue.

Comment 30 by, Jun 6 2017


Comment 31 by, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt

Comment 32 by, Feb 18 2018

Labels: -Hotlist-EnamelAndFriendsFixIt

Comment 33 by, May 2 2018

Any movement on this six-year-old security hole?

Comment 34 by, May 18 2018

Turn auto-fill off. There is no way to reliably detect this, unless a special DOM element is made for auto-filling forms, which is really bad for custom UI. 

There are always ways to exploit auto-fill because of the way it works, and there is no easy alternative.
Best way for those who are concerned, just turn auto-fill off. There is always a trade-off between ease of use and predictability. For practical reasons ease of use is chosen.

Comment 35 by, May 18 2018

It doesn't have to be perfect solution right away,
not auto-filling fields that are not drawn (i.e. hidden) would drastically minimize impact of this problem.

Comment 36 by, May 29 2018

Autofill folks, do you have any updates on this bug?

Comment 37 by, May 29 2018

The suggestion to "just turn auto-fill off" is missing the point of this bug post.  The point is that Chrome's behavior when it encounters honeypots is to fill those hidden values just as a malicious SPAM bot would.  That is not correct behavior.  Other browsers have autocomplete features that DO NOT behave this way. Chrome is ALONE in this unusual behavior. 

So when a user tries to fill out a form that includes an anti-SPAM honeypot, they won't be able to submit the form because of Chrome's autofill behavior.  Site owners can't reasonably solve the issue by telling everyone to "just turn auto-fill off." Instead, Chrome should act appropriately and not auto-complete hidden fields that the user had never filled out in the first place.

Comment 38 by, May 29 2018


Comment 39 by, Jan 14

Any updates on this pretty annoying issue?

Comment 40 by, Jan 14


Sign in to add a comment