Can web-to-lead be protected from spammers without additional server side processing?

Question

The default web-to-lead functionality that Salesforce provides makes it really easy to drop an HTML form onto any web page and submit leads straight into a Salesforce Org.

E.g.

<form action="https://www.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8" method="POST">

    <input type=hidden name="oid" value="00D100000000001">
    <input type=hidden name="retURL" value="http://">

    <label for="first_name">First Name</label><input  id="first_name" maxlength="40" name="first_name" size="20" type="text" /><br>
    <!-- Additional fields -->

    <input type="submit" name="submit">
</form>

Looking at the generated HTML the only input that is unique to your Org is the oid. Once a bot/spammer has that they could easily POST data to /servlet/servlet.WebToLead and create as many leads as they want (upto the default 500 per day).

While it is great the web-to-lead is so easy to implement it opens you up to receiving lots of form scrapping spam. Worse still, once your OrgId is out in the wild and they know you are using web-to-lead you can't just fix up the form to stop the spam coming in. You'll be forever trying to pickup the pieces with validation rules and field validation. See also - Ideas: Web 2 Lead & webform spam

Since the oid/OrganizationId is so sensitive it seems like it shouldn't be in the form in plaintext and ideally shouldn't even be sent to the client.

Do people just resort to server side processing to create the lead (and hide the OrgId) or is there a way to secure the generated form?

Of course, once you are doing server side processing you don't really need to use web-2-lead and can use the APIs instead.

Answer 1

New Spring 17 Feature

Both Web-to-Lead and Web-to-Case now have out of the box reCAPTCHA support. When creating the form you will now see "Enable spam filtering (recommended)" and "reCAPTCHA API Key Pair" fields:

Here's the former solution, without using CAPTCHA:

1. turn the "URL" field into a dedicated honeypot / gotcha on your Web-to-Lead form. Render it invisible using CSS, and then when you see a Lead come in with LeadSource='Web' and !ISEMPTY(URL) you can blackhole it. (Subject to your existing business processes of course)

2. pull the oid organization id value out of the hidden field and populate it later using JavaScript: <script>document.getElementById('oid').value = '00Dd00000001234';</script>

These will choke most dumb scrapers and keep spam to a manageable level.

Answer 2

There's not much you can do to protect your web to lead forms without additional code. In fact, this is why there are solutions on the matter (see Help & Training). The problem stems from the fact that salesforce.com isn't in control of the form, and has no way to submit any errors back to the original form. This is a necessary trade-off in order to provide generic web to lead functionality.

For advanced functionality, one must turn to either one of two types of solutions: (a) web server implemented logic, like captchas, that verify the data was human submitted before sending the data to salesforce.com, or (b) a validation rule or trigger in salesforce.com that blocks malicious submissions after the fact. Either way isn't perfectly reliable, because spammers can and do often change their tactics (for example, CAPTCHA farms, changing keywords, etc), making combating spam increasingly more complex as time goes on.

Unless your form is being bombarded, it is probably best to just go with the out-of-the-box mechanism; once they have a copy of the web to lead form, they have your org ID, and they can spam you all they want despite the form being fixed or removed. If you're in this situation, a custom form using the API might be your only option. If you have never released your org ID in the wild, then you might consider a server-side validate and redirect before you ever expose your org ID, using a socket to directly submit the lead to salesforce.com from the server, or simply using the API.

Personally, I find server-side submissions to be the easiest; PHP, Perl, and Ruby all offer easy ways to connect to a remote server and post a HTTP request, without exposing your org ID and other hidden data to the server (e.g. a campaign ID).

Answer 3

On my side I am also changing the form destination via JS. This would be equally effective against robots that do not run JS as some of the other solutions proposed.

<form action="http://www.example.com/sorry" ...>
<script>
jQuery("#investor-web-to-lead-form").attr("action","https://www.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8");
</script>

More info on this is also available here: https://daddyanalytics.com/salesforce-web-to-lead-spam/

Answer 4

In addition to @mattandneil excellent recommendations with respect to how to hide the org.Id until it's populated via JS, I've used the jQuery Validate plugin to do validation from within the web page to help reduce spamming for a client.

This all happens before the Ajax event occurs that sends the data to Salesforce. I found it much easier to implement than Google's RECAPTCHA and also feel it's far more user-friendly. The one possible exception being that it doesn't currently have support for the visually impaired.

Edited 02/0/2020 RECAPTCHA has been updated since this answer was originally written to provide support for the visually impaired and is available as an out of the box feature.

Answer 5

The other two responses are correct and spot-on. If I could add anything, it's that the most important thing to prevent long-term spam problems is to never release your Org ID into the wild, and if you have, get it off your website as soon as possible.

In your Salesforce setup, as long as you have Web to Lead enabled, then anyone who has your Org ID can spam you, directly from their servers, regardless of the state of your forms. Without that Org ID, they can spam your form but not directly spam your org.

The easy solutions around this are to use a custom php/cgi/whatever script, or one of the many plugins such as the Wordpress to Lead plugin or the Drupal Webforms add on, or hosted forms like FormAssembly.

If you have Enterprise and higher than you can disable the Web to Lead functionality and use the API to get your leads in there, but if you are Group or Professional, that option isn't available to you, so try to keep your Org ID hidden from the start.

As for stopping spamming of the form itself, there's a lot of solutions out there, and the obvious ones are indeed Captcha's, etc., but if you've taken the above approach of using a plugin or a hosted form provider, then that's normally a feature of that form itself.