Frequent Bot Attacks

[Robb_Barrett]

Hi all, I know this is an often discussed issue but I'm going to start this discussion anyways. We've been getting hit lately. Honeypots don't work, mandatory fields don't work. We have some assumptions that I'd like to open up here for discussion:

• The bot is looking for /contact-us or /contact on any domain
• The bot is using direct API to pass data, not the form
• The bot scrapes the page looking for the embed code to get the needed info

With that, we have a couple of thoughts on potential solutions:

• Obfuscate the form embed info by hashing the Munchkin ID and the form ID
• Change the URL from /contact-us to something different, like /talk-to-us
• Block all traffic from IP address 122.54.253.2
• Storing the form embed code in an external JS file so it's not easily readable

Our solution assumption is that this is a script and changing the embed code in a customized way would break the script from knowing what to do. 

• We don't want to reCAPTCHA due to the bad user experience and the need for multilanguage versions.
• The Etumos solution is cool, but that could get costly when we get hit with thousands at a time and that solution only works when the form is respected.
• Sometimes we find that it uses actual valid email addresses
• Because we've seen the form submit without mandatory fields, we're assuming that it's not respecting the form embed script and it's building it's own form code.

Following these assumptions, we wonder if hashing out the mktoForm_12345 and the munchkin string would make it impossible for the script to build it's own version of the form by scraping our page. We feel that the solution needs to be server-side for best results since it would be harder to reverse-engineer our changes. If that's not possible, then simply changing the code - for example, by placing a variable in place of the form ID and munchkin ID, would also break the script.

[SanfordWhiteman]

There's no hashing that has any effect. Everything done browser-side is readable, alterable, and bypassable; the HTTP request is put on the wire where any eavesdropper can read it. Every part of the payload could be hashed and it would be just as easily replayed by a bot farm, since the hashing would (by definition) be done in the browser.

Sorry but the solution is reCAPTCHA. It exists because other methods didn't work. And it is multilingual. As for the UX, well, you start with the reCAPTCHA v3 or the v2 invisible reCAPTCHA, which eliminates the need for end user participation. Furthermore reCAPTCHA is so common -- being used on the world's most-trafficked sites -- that it's becoming a standard part of the HTML form experience. I wouldn't knock its UX effect on conversions unless you've actually A/B tested it, which in your case is going to be difficult if you can't process forms effectively due to bots anyway!