Many of our Digital Pi clients experience bot attacks on their Marketo forms wreaking havoc on database health, aggravating sales reps with automated notifications, and even diminishing system performance. As more companies embrace Marketo for their marketing automation platform of choice and publish more Marketo forms on the web, Marketo forms are increasingly targeted by spammers.
Let’s get something out of the way up front: there is no way to truly block or prevent form submissions with Marketo. We can prevent Marketo forms on the web from being submitted by real users, but we can’t block the submissions themselves. That can only be done at the server level and, as users of the Marketo web application, we only have access to Marketo at the UI and API levels. Truly refusing connections and posted data from form submissions would require server-level access that Marketo has never, and probably will never, grant to customers.
So if truly blocking Marketo form submissions from bots is off the table, what are some creative alternatives to deal with these submissions?
Validation
First, we want to ensure valid input from the web page where the form lives. Marketo forms already have most of the common validation logic pre-baked into them, but the native functionality can be augmented with custom validation logic if desired. For example, requiring a business email address that is not a gmail.com or hotmail.com is one good tactic that ensures real people enter real, valid information.
However, it breaks down for bot detection. Bots are, in essence, computers and don’t interact with a visible form the way a human does. They can easily bypass the web page altogether simply by posting a form submission directly to the Marketo servers. (Indeed, under the hood, this is what Marketo itself does natively with its forms except that the forms are configured to require users to first pass the built-in JavaScript data validation.)
Although it’s still worth the effort to get good data from real people, Marketo’s native JavaScript form validation is, for nefarious actors, laughably simple to circumvent. In short – it is entirely ineffective for preventing spam bot submissions. Marketo does not seem to do the same validation on the server side that exists in the forms themselves on the front end (a best practice). If our Marketo instance were a fortified castle, it’s the equivalent of leaving the drawbridge down, allowing attackers to ride their horses right over the crocodile-filled moat.
Detect, Then Deal
The next logical approach, then, is to attempt to detect bot form submissions in Marketo flow logic and deal with those records accordingly. The most common approach is to find characteristics that repeatedly appear on spam submissions. Perhaps they all come from the Philippines. Maybe they all come from the same IP address. Perhaps they all have “qq” in the email address, or maybe they all have the same Chinese characters in the last name. But you usually don’t want to just blindly delete all form submissions with these characteristics. So, we build filters to look for these values and find matches in the database, then deal with them accordingly.
Of course, a smart spammer can easily change any of these by mixing it up with each form submission making it more difficult to detect. But alas, event the most valiant Marketo admin will be kept guessing, perpetually several steps behind the dastardly spammer.
So what to do?
There are two common practices:
- Use a hidden honeypot field (or fields) that, when filled with data, mean this form submission did not come from a real person.
- Employ CAPTCHA, those annoying “enter these misconfigured characters” or “select all the store fronts” challenges at the bottom of the form.
Honeypot fields are a decent idea: hide a field on a form that a real visitor will never see or fill out. This is an elegant idea because it does not impact or impede human visitors from completing Marketo forms. However Bots, being computers, can see it because the field is part of the form’s HTML markup. The rationale is that bots are not sophisticated enough to not enter a value in the field. If only ’twere so simple.
The hackers behind those bots are savvy to this practice and can choose to simply ignore all hidden fields, placing no values in them and thereby escaping detection. It doesn’t hurt to have them on your forms for those unsophisticated bots that take the bait, but it’s certainly not going to fool all spammers. Rats!
Solve a CAPTCHA
To take a more hard-line approach, we can ask users to solve what is called a CAPTCHA—an antiquated acronym for Completely Automated Public Turing test to tell Computers and Humans Apart. For our purposes, that’s a fancy way to say “detect a real person.”
By far the most common solution is Google’s reCAPTCHA. However, some clever cybersecurity researchers on the unCaptcha project at the University of Maryland’s Department of Computer Science recently demonstrated the ability, with minimal computing resources and online services (some from Google, no less), to solve Google’s latest iteration of reCAPTCHA in about five seconds with a 91% success rate, and the code to do so is publicly available. (Their 15-page report is a fascinating read, if you feel like geekin’ out for a while.) It would seem that even Google, with all its technical might, is still, like our beleaguered Marketo administrator, thwarted and behind the eight ball. Argh!
A Marriage of Two Solutions
After some serious head-scratching, and reluctantly accepting that we’re not going to out-think these incredibly sophisticated hackers, we decided to marry the two approaches, but simplify the logic. In other words, employ not only a front-end authentication mechanism, but also verify from the back end and adjust operational processes accordingly.
We created a surprisingly simple system to generate an encrypted authentication token with a limited expiration date and submit it with valid form submissions, then decrypt and evaluate it within Marketo to ensure its validity. Any records that pass the back-end validation are allowed into the system as usual, while those that do not pass are considered suspect and thus quarantined for human review. Quarantined records are excluded from normal operational routines like lead scoring and lifecycle processing. When removed from quarantine (by simply removing them from a static list in Marketo), all the processing that was prevented is automatically triggered as usual.
It’s an automated way to say, “Hey, something’s fishy here; don’t let that one through until somebody checks it out,” and to do it at scale.
In client production scenarios—in the real world, and in the face of persistent bot attacks on Marketo forms—we have observed a bot-detection and quarantine rate greater than 95% success, while false positives have occurred in less than 1% of quarantined records when the front-end validation script failed to load or fire.
The catch is that it requires a web server to host a simple web service. We can work with clients’ IT teams to provision a suitable server, or, if an existing web hosting environment, such as the one hosting the company’s main website, meets the very basic and common requirements, the service can be hosted alongside the main website.
One Last Layer of Protection
In addition to any or all of the above approaches, there’s another layer of protection that can be set up: a firewall. This is an exception to my earlier statement that form submissions to Marketo cannot be blocked, because this setup actually does happen at the server level. It is less common than the other approaches but can be employed in conjunction with the honeypot, CAPTCHA or encrypted token methodologies.
Marketo users can benefit from the use of a firewall—or a web application firewall (WAF). CloudFlare is a common WAF choice, although there are many others. A WAF can filter web traffic bound for Marketo—web page requests, search engine crawlers, form submissions and more. In CloudFlare’s words, it allows you to “control incoming traffic…by filtering requests based on location, IP address, user agent, URI, and more.” Essentially, this setup routes requests through a third-party service prior to making the request of Marketo. If a request seems to be legitimate, it is transparently forwarded to Marketo, and the response is relayed back to the user. Real users are rarely aware that this is happening, but a WAF may be helpful in preventing suspicious traffic—such as a bot-induced form submission—from reaching Marketo at all.
Depending on which WAF you employ, you might have different options. CloudFlare’s easy-to-use system offers a free plan that enables, among other things, blocking or challenging suspicious traffic and IP blocking for repeat form-bot offenders. You will need to discuss this with your IT team and work with them to set it up.
Are bots attacking your Marketo forms? How are you addressing it? What have you tried, and what is working for you? Let us know in the comments below.
