Spam bots are the worst.
They can ruin a good contact form in a heartbeat.
While getting rid of spam bots requires a lot of strategy and technology, simple honeypots are quite effective for their low effort.
What is a honeypot?
In the world of cybersecurity, there are many types of honeypots, but they are all essentially bot traps.
Today we are talking about honeypots used in frontend forms.
When bots spam your contact form, they must read the page source to “see” what to fill out. The good news is bots don’t “see” like humans.
This is precisely what a honeypot exploits.
The process will look a little something like this:
Create a fake input inside a form
Hide it from the human users but not the bots
Filter for the field in your backend
It would look something like this.
Setting up the honeypot field
Let’s pretend we have a basic contact form:
<form action="/submit" method="POST">
<label for="name">Name:</label>
<input type="text" id="name" name="name" required>
<label for="email">Email:</label>
<input type="email" id="email" name="email" required>
<label for="message">Message:</label>
<textarea id="message" name="message" required></textarea>
<button type="submit">Send</button>
</form>
Bots will fill out every input and submit our form, so we need to add our honeypot.
<form action="/submit" method="POST">
<label for="name">Name:</label>
<input type="text" id="name" name="name" required>
<label for="email">Email:</label>
<input type="email" id="email" name="email" required>
<label for="message">Message:</label>
<textarea id="message" name="message" required></textarea>
<div class="phone">
<label for="phone">Phone:</label>
<input type="text" id="phone" name="phone">
</div>
<button type="submit">Send</button>
</form>
We added an extra field called phone
. This field should not be visible to the user but should be visible to bots. To hide the field, we can add a simple CSS rule.
.phone {
display: none;
}
The user will not be able to see our honeypot, but bots will. And when they see it, they will most likely fill it out, which means we have them trapped.
Make sure you pick a good name for the honeypot
Before we discuss how to deal with this extra field in our backend, I want to point out one thing.
The name of our honeypot shouldn’t be random.
These bots are aware honeypots exist.
They have logic that filters out any irrelevant inputs when completing forms.
So if we create a field called random or, even worse, honeypot, we tell the bot the field is a trap, so they should avoid it.
Instead, we should consider related topics or fields related to the form.
In most contact forms, that means we’d add anything related to contact details like:
Trap the bot and kick it out
Now that we have the honeypot set up on the frontend we need to handle it in our backend.
I set up a pseudo-express
route to show the basic logic of handling this extra field.
app.post('/submit', (req, res) => {
const { name, email, message, phone } = req.body;
if (phone) {
// If the honeypot field is filled, it's a bot
console.log('Potential bot detected');
res.status(400).send('Bad request');
} else {
// Process the legitimate submission
console.log('Legitimate submission:', { name, email, message });
res.send('Thank you for your submission!');
}
});
We pull the honeypot off the body and then check if there is a value.
If there is, we caught the bot!
Send back a 400
error and sit back as your form zaps bot after bot.
More than one honeypot
In the last few years, I’ve noticed the effectiveness of one honeypot isn’t what it used to be.
The good news is we can add more honeypots.
This is a bit more effort but can bolster the strategy’s effectiveness.
Remember to keep all honeypot names related to the other fields in the form, and we should be good to go.
I’ve been using three honey pots per form, which seems to be the sweet spot.
Let me know if you have questions.
Happy coding 🤙
Top comments (13)
Honeypots are great! Of course, a bot can now pretty easily check what inputs in the form are hidden and not fill those out, or instead of using the website, use the form API itself (as they often do now).
In that case, we have to rely on other techniques or bot challenges (like Cloudflare with a required Cloudflare token in the API request). Of course, there are new ways to circumvent those methods as well.
Nice article!
Back in the late 90's, early 2000s, I had a form bot hit one of my forms pretty hard. Hundreds of emails flooded my mailbox. What I found was the bots don't know what they are doing, and they end up putting URLs in many of the fields. Knowing that there is no reason for a URL to be valid data in any of the form fields, I look for a URL in the data as one of my rules. If I see a URL in a field, the page is automatically redirected to FBI dot gov :D
Another thing I do is validate that any drop-downs have valid data in them. I expect values coming back to be a valid option value coming in. The bots were putting URLs in those fields too, which didn't make sense.
lol I love the redirect. Great points all around. Thanks for sharing!
damn :), Mr you have my respect 😅
Thanks for this, glad it's different from the other cliche ones
‘display: none’ removes items from the DOM, so how are the bots meant to find this field?
Great question! Many bots simply parse the raw HTML without CSS applied, which means they will "see" the field and complete it.
But this brings up a great point: honeypots can be set up in other ways by setting opacity to zero or moving the field off the screen with absolute positioning. Sophisticated bots will know to look for setting the display to none. That's why I mentioned this isn't a complete plan, but it works well for the effort.
Another reason setting display to none is used is because screen readers won't pick up on the field either, so it makes sure the form is accessible to others.
Let me know if you have more questions!
Be careful with regards to accessibility, for things like tab order and screen-readers. Often the work we do to make the form more accessible to humans also makes it more exploitable by bots!
No doubt. Great point! Software is a game of trade offs
Ah, I did not know that about bots, thanks. So people use bots like this to perform actions on a website not just scrape them?
Yeah. Often, it will be to pitch random services or phishing schemes that have nothing to do with your form's content.
I use a honeypot in which the user is asked to fill out a date field; if it matches the calculated value on the back end, all is good.
I like that! I'm going to keep that in mind for future forms