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

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.

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).

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/