DEV Community

Cover image for How To Stop Form Bots With Honeypot Fields
Jeff Jakinovich
Jeff Jakinovich

Posted on • Originally published at jeffbuildstech.com

How To Stop Form Bots With Honeypot Fields

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>
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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;
}
Enter fullscreen mode Exit fullscreen mode

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.

Diagram of what user sees vs. what spam bot sees

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!');
    }
});
Enter fullscreen mode Exit fullscreen mode

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)

Collapse
 
best_codes profile image
Best Codes

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!

Collapse
 
x2rider profile image
Paul Reedy

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.

Collapse
 
jeffbuildstech profile image
Jeff Jakinovich

lol I love the redirect. Great points all around. Thanks for sharing!

Collapse
 
rafaeljohn9 profile image
JohnKagunda • Edited

damn :), Mr you have my respect 😅

Collapse
 
rafaeljohn9 profile image
JohnKagunda

Thanks for this, glad it's different from the other cliche ones

Collapse
 
laurenceokite profile image
laurenceokite

‘display: none’ removes items from the DOM, so how are the bots meant to find this field?

Collapse
 
jeffbuildstech profile image
Jeff Jakinovich

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!

Collapse
 
moopet profile image
Ben Sinclair

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!

Thread Thread
 
jeffbuildstech profile image
Jeff Jakinovich

No doubt. Great point! Software is a game of trade offs

Collapse
 
laurenceokite profile image
laurenceokite

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?

Thread Thread
 
jeffbuildstech profile image
Jeff Jakinovich

Yeah. Often, it will be to pitch random services or phishing schemes that have nothing to do with your form's content.

Collapse
 
nosnetrom profile image
Jim Mortenson

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.

Collapse
 
jeffbuildstech profile image
Jeff Jakinovich

I like that! I'm going to keep that in mind for future forms