Spam is one of those things we wish didn’t exist. It’s annoying and serves no useful purpose. Mail inboxes filled with junk mail, websites with bogus contact form submissions, and products hit hard by fake sign ups are only a few common victims of spam. And unfortunately that’s here to stay.
You may have found yourself on the receiving end of such problems. In fact, you may have reached this blog post in your research to rid or lessen your spam problem. Fortunately you’ve arrived at an answer. The Honeypot technique is a fast, easy, and effective means to prevent spam.
Before I go into detail on how to implement the Honeypot technique, I want to cover two other options that are still in use to prevent spam, and why you shouldn’t use them.
Two Spam Prevention Options I Avoid
The first is Captcha. A captcha is an image that renders text in an not-so-easy-to-read way, also known as challenge text. By requiring users to type the challenge text into a text field, it verifies some form of human interaction and intelligence. So if what the user enters matches the challenge text, the user is said to have successfully completed the challenge and their form submission is allowed to proceed.
A captcha displayed as part of a login form.
Spam bots, on the other hand, often lack the intelligence to defeat the challenge. First because the challenge text appears in an image, not html markup, reducing their chances of reading it. And second, because they’re often unaware that the form field attached to the captcha is looking for a specific entry. Most spam bots fail captchas due to one of these reasons.
A second option is implementing a question and answer field. For example, a sign up form may include the following question: What color is an orange? Humans can easily answer that question, whereas spam bots won’t be smart enough. Once submitted, the answer to the question can be tested. If it’s correct the form was likely submitted by a human and can be handled accordingly.
Both Degrade User Experience
While both options are easy and help prevent spam, I don’t recommend them because they interfere with the user experience. Often times they’re frustrating to deal with and motivate users to leave. A good example of that would be captchas that output text too hard for even humans to read.
For that reason I always recommend implementing the least invasive option available.
Enter The Honeypot Technique
The reason the Honeypot technique is so popular is because in addition to how easy and effective it is, it doesn’t interfere with the user experience. It demands nothing extra of them. In fact, your users won’t even know you’re using it!
To implement the Honeypot technique, all that’s required is adding a hidden form field to the form in question. The form field can have any name or id associated to it, but make sure to add a display: none CSS rule on it (or some other means to hide it from users). Here’s a brief example:
<input id="real_email" name="real_email" size="25" type="text" value="" /> <input id="test_email" name="email" size="25" type="text" value="" />
#test_email {
display: none;
}
Note that I have 2 email fields, real_email and test_email. test_email is hidden via display: none, so it’s not visible and likely can’t/won’t be submitted by real users.
And that’s what gives away whether the form submission is spam or not. Real users don’t see the hidden field so they won’t submit it with any value. Spam bots, however, will still see the field in the form’s markup, auto-populate it with something, and submit it with the rest of the form.
So from there all that’s needed is to test whether the hidden field was submitted with a value or not. If it was, the submission can be treated as spam.
And remember, because the field is hidden and out of view, users don’t even know it’s there, which is why this approach to spam prevention is far more user-friendly vs. requiring they complete a captcha challenge or answer silly questions.
Conclusion
Spam is here to stay, but fortunately the Honeypot technique offers a fast and effective way to prevent spam. Even though there are other options to consider, keep your users in mind and always prefer the least invasive approach to mitigate spam.
All the Honeypot techniqure requires is adding a hidden field to the form in question. With that, just about any form can become spam free.
I go just a bit further – instead of using CSS to hide the field, I use jQuery:
$(‘#test_email’).hide();
And then, in order to prevent a legitimate user with a form populator plugin from tripping it, I add this to my submit button to clear that form on a legitimate submission:
id=”form_submit”
$(‘#form_submit’).click(function(){
$(‘#test_email’).val(”);
});
Hi Paul,
Thanks for commenting.
That idea can work as well, at the expense of requiring jQuery and additional JavaScript. Although another option to consider is naming the #test_email element something more obscure (e.g. a hash or timestamp) so that form auto-populators don’t write to it. That way a simple rename addresses your improvement, vs. having to add JavaScript to the mix.
@Paul
Why would you use jQuery to hide an element that you always want hidden? Doing so is adding extra JavaScript processing to the page, and manipulates the DOM causing a redraw. Also, since jQuery.hide() adds inline styling
style="display: none"directly onto the selected element, a smart spam engine might be looking to NOT fill in elements marked with “display: none”. Sure the spam engine could still get the computed CSS, but that is much harder to get.The preferred approach is described in the tutorial above (i.e. using pure CSS).
Using Javascript would rule out bots not reading Javascript, some may read CSS and see it’s hidden.
Also if you’re using this technique and are not using jQuery for anything else on you’re page, just use vanilla Javascript
jQuery’s hide() just adds inline style “display: none” which I’m assuming the bots can read too. So “use js to hide” seems like bad advice to me.
You can add a delay of a few seconds before you do the hide(), but then real users might see the fake field.
Like Pete said, a smart bot can detect whether or not a form element is hidden. That’s why I prefer not to hide the honeypot but move it out of sight.
position: absolute;
left: -999em;
Depending on the form/site, I also check the time between when the page is ready and the form submission. Then I determine the minimum time a human needs to fill and submit the form, if it’s too quick, I reload the page without submitting the form.
That last solution is not acceptable for users that use assistive technologies. The field is only hidden for users that can see the page, but what about blind or partially blind people?
However, the js click function excludes ‘de facto’ users that use only the keyboard to fill in and validate the form.
Just name the filed “Leave Empty” and then hide it with:
position: absolute;
left: -999em;
The spammers add delays so that it fills the form out slowly like a human. They can pretty much write to whatever we do to try to prevent them. They can even tell the bot not to fill out form fields with negative margins greater than 100 or whatever. Obviously, they’re gong to write in there not to fill out fields with display none on them or visibility hidden. That’s why, as much as I hate them, captchas are the only method that makes it really difficult for the bots to get by. The honeypot method is just a few extra lines of code for them. It’s just too easy. I think it’s worth trying it until it fails though. Why not?
What about autofill of such fields? With a name like “email” this field is likely to get filled automatically and without manual action by the user. Usually, I use autocomplete=”off” in such fields/forms, but that’s still a bit problematic …
autocomplete=”off” is now obsolete, the workaround is autocomplete= new-password
thanks it’s so simple and works easily on my site.
Is honeypot still reliable? What’s to prevent a bot script from just determining whether a field is hidden or not?
Some may argue that it’s not, but try it’s easy enough to try and it’s been proven to work well for a lot of people. In our case it’s helped filter out just about all spam submissions to our sites and apps.
I’m not a coder myself (though I’ve taken enough classes in college to do some basic stuff). Does anyone know where I might be able to find a DIY method for an updated honeypot version beyond the basic strategy of hiding the field from a bot as shown in the article?
By the way, I am using this on a landing page (lead capture), so I want to stop bots from opting-in.
Matt, not sure if you ever got an answer to this – I’m not a coder either, but most (if not all) form tools that non-coders would use allow the option to make a field “hidden.” When you choose this option it slips in pre-built CSS that does exactly what this article is talking about. Then as you export, download, or however you process your leads, you exclude the ones that have the hidden field populated.
You can listen for window.onmousemove (for desktop) and window.onorientationchange/ontouchstart (for mobile) events and require a certain amount of variation from the inputs to determine if your user is human. I believe this is how Google’s “are you a robot” auto-captcha works
Slick, but remember a lot of bots have JavaScript turned off. I guess you could always reject submissions from users with JS disabled. This would depend on your client though. Certain industries this would not be acceptable.
Another method, which I used with success on a high traffic site, is to treat all submissions that contain links as spam. Obviously this won’t suit the times when you want people to submit links, but if you’re expecting just a comment, and inform your users that links are not allowed, then you’re covered. Pretty much all spam contains links. Have the form submit “successfully” but really it’s not because the javascript found links and didn’t apply the true form action URL – which you should only add to the form with JS on load, then remove it on submit if links found. We got zero spam for 2 years on a high traffic site using this very uncomplicated method. UX is superb, just “write your name, write comment, submit”. No other steps, and doesn’t interfere with screen readers or other accessible problems, just needs simple javascript/jquery alone. Server side doesn’t need to do anything different either, it never sees the spam because it’s never submitted.
Really like the sound of this approach!
But….” just needs simple javascript/jquery alone.” Great, but what javascript/jquery is it? I don’t write code! Is it available?
Thanks
Thanks for the article. I implemented honeypot using gravity forms for one of my client websites and it has reduced spam to nearly zero. Within the last 2 weeks, we’ve been getting 1-2 spam emails a day that are all similar in nature. They contain statements in the comments like…”My hobby is mainly Book collecting.
I try to learn Swedish in my free time.” All of them have bogus emails and phone numbers. Have you heard of this type of spam? I can’t imagine a human typing these in and have no idea what their goal is? Any suggestions to stop these would be appreciated! Thanks again for your great content!
Dave
Hi Dave,
No, I’ve never received those particular spam submissions.
Though as Ryan mentioned above, you may have luck timing the problematic form. E.g. if it’s submitted in less than a second, then chances are it’s a spam submission.
Pingback: How To Stop Website Spam
I’m not a web programmer, so don’t entirely understand what you’re trying to do. Does this result in the spammer submitting a form with this javascript code? Where does it go?
What do you do with the info once you’ve gathered it? How do you use it to block future attempts at your mail server?
Hi Dave,
No. The spam bot will indeed submit the form, but not with or through any of the JavaScript options other comments have mentioned. It sounds like JavaScript has been mentioned only as a way to hide the honeypot field. And as others have commented, that’s probably unnecessary since the same thing can be done with CSS.
When the spam bot submits the form, it still routes to whatever server side script you specify for the form. The test comes in detecting if a value was submitted for the hidden field or not. If there was, then it’s most likely a spam submission b/c real users wouldn’t have filled anything in for the field since it was hidden.
I haven’t heard of wide spread gathering of spam submissions, other than underlying spam prevention plugins or software (e.g. Akismet for WordPress, or IP Board’s spam control). Rather, if a spam submission is detected, it’s simply ignored instead of processed. That’s the scope of this technique.
As far as blocking future spam attempts, best of luck, b/c unfortunately spam will always be with us. 🙁 I will say that this technique has been very successful in helping us ignore spam submissions. But if you wind up needing something more thorough, try seeking out spam prevention plugins.
Hope this helps.
Thanks very much for the explanation.
Pingback: Web Forms and the User Experience — Scott W. H. Young
Is there a way to simply abandon form submission if the hidden field contains any input. For example for the OnSubmit check to detect if the hidden field contains any data and to destroy (abandon) the form if it does without sending it to the recipient.
Yes, but I suspect you should send the bot to the thank you page rather than just denying the send, otherwise they are likely to keep trying.
Once they reach a thank you page with a 200 reply, they are likely to give up.
Some developers are fighting with me saying this technique blocks targeted script attacks. Against spam bots this will work, sure. Against an attacker that inspects the site first and sees how it functions, absolutely not.
Pingback: 12 Tips to Optimize Your Web Forms for Lead Generation
I am thinking of adding a simple PHP script to the honey pot system, that if the hidden field is (NOT) empty, the form is not submitted. Would that not work? If the field is populated, then it wasn’t filled out by a human??? I don’t pretend to know a whole lot about this, but want to validate my email, and don’t want to turn people away. My target audience is an older demographic, and captcha’s are out of the question. Simple math (might) be ok, but honey pot seems better if foolproof(ish). Thanks. gp.
You’re correct, Glenn. If the hidden field was submitted with a value, it should be treated as spam.
The rationale is that since a real user wouldn’t have seen the field, they wouldn’t have entered any value for it. So an empty value for the field is a good signal that the form was submitted by a human, while a non-empty value signals spam.
And yes, since you mention PHP, it can easily test the field value, just as you’d test any other form value.
Good luck!
Hiii
Thanks for aware us such nice technique. Its really helpful Article.
Pingback: Port80 Software | 200ok IIS Security Blog
Pingback: PINT Blog | It’s 2016! Why are we using CAPTCHA?
Lot of good ideas! Spam is such a pain…
Pingback: Sell More With Elementor Pro: New Price Table & WooCommerce Widgets - Elementor
Here’s a fun fact I figured out by accident. You can also comment out a form element with HTML comments (), and many bots still submit it:
<!–
–>
I have had very good success with this method of “hiding” the form element as well.
it appears the html was parsed out of my previous comment. But I hope you get the idea. just use html comments to turn your form element into an html “comment”. Many bots will still submit it.
I don’t get how if this invisible field is filled out it will be marked as spam. How would that mark it as spam?
I am looking at using this with a commenting extension in Joomla. It seems like there would need to be a php file too. IDK I am no expert on this stuff.
Hi Ian,
the hidden field doesn’t affect the form being posted but when this takes place the payload of the form is checked server-side. If the field that was hidden in the UI is found to be populated then further processing of the form and message sending is abandoned. But otherwise the response back to the client is the same and an acknowledgment or error message page/view is served up to the user (in this case the spambot). As Tom, above, stated give the spambot a HTTP 200 status code.
Hope that helps.
Regards,
Nick Bergquist
May be even intercepting the form submission with javascript and appending a field to it and then submitting from the javascript code would do the trick. This is untested and does not guarantee to help in solving your spam problem.
Oh yeah and one can’t check for theese css hidden form fields ?
Pingback: Avoiding spam without CAPTCHA widgets - AdFury
Pingback: Howto: create a front-end profile edit page in WordPress - WPcode
After considering all the comments, I came with this solutions to minimise the risk and/or make harder for the spam bots.
Add “tabindex” attribute to prevent tab from the user (this is optional).
And using CSS make the input field completely invisible by the user. Here is the full code.
HTML:
CSS:
#test_email {
background-color: transparent;
border: none;
position: absolute;
left: 0;
top: 0;
cursor: default;
pointer-events: none;
color: transparent;
}
#test_email:hover{
height: 0px;
cursor: default;
}
#test_email:blur{
height: 22px;
cursor: default;
}
#test_email:focus{
height: 0px;
outline: none;
cursor: default;
}
Hi there, yeah this article is really good and
I have learned lot of things from it concerning blogging.
thanks.
Thanks for every other informative blog. Thee pace else may just I am getting that type
of info written in such a perfect approach? I’ve a project thhat I am
just noow operating on, and I have been at the glance out for such info.
I am experiencing malicious login attempts in my new wordpress blog. Thanks for sharing this great insights!!
I will definitely implement them especially the Honeypot feature
Update 2018: Honeypot in the real world is still effective with no captcha. If I turn it off, I get batches of 10-30 spam blog comments. Turn it on and get none. Just FYI.
We use honeypot on all of our websites. I try not to use any captcha because it definitely ruins the user experience.
I had implemented this and it was working well until I noticed I was starting to get a bunch of false hits. It took me a while to figure out that the reason was that Firefox’s autofill feature would fill in hidden fields. I had named the field “Middle” and it was filling in middle names of users who had them on file. So I changed the name of the field to “happy” and now it doesn’t get any hits at all. Any suggestions for a field name that would not be covered by autofill features but would still fool robots?
Use autocomplete=off parameter in the input tag.
Pingback: php - Luchando con recaptcha v2 y envío del formulario
Pingback: What’s new in nopCommerce 3.60 – Nop4Pro
Captcha just isn’t working on my site, as my Sign ups have dropped significantly ever since I added it to reduce the ridiculous amount of Spam from bots I was receiving.
It feels that fewer people are even finding my site, with the new Captcha, let alone those who don’t want to complete it. In 10 weeks of Captcha my Sign ups have dropped from an average of 15-20 a month to 3. It’s a disaster!
Reading about the Honeypot technique it sounds an attractive option as it seems it is the least invasive.
Do you feel confident that with this on my site my usual amount of Sign Ups should return to normal??
Pingback: Get Google ReCaptcha to work around the world – Gregory J Development
Pingback: Basic ProcessWire website workflow - Part Two - Abdallah Samy
Pingback: How to reduce spam accounts on your Shopify store - LaunchTip
is there actually any way knowing and tracking how many “fill outs” honeypot received from bots?
Thanks for compiling this.
To quote a section of your Honeypot description:
“So from there all that’s needed is to test whether the hidden field was submitted with a value or not.”
It would be very helpful to explain “test”, as the first part is pointless without this explanation.
Thanks