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.


<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">

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.

5 Answers 5


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.

  • The latter solution is probably better, since most spammers aren't going to check your JS code to see if they're missing anything, unless they have someone simulate the form submit to start with, which isn't time effective.
    – sfdcfox
    Jan 9, 2014 at 21:28
  • dont you have to add an id to the oid input? Your javascript looks for an id, but the oid input does not have one. You should probably also change the id name from oid as that is recognisable
    – Jon
    Jan 20, 2016 at 13:28
  • Unfortunately, spammers have gotten wise to the JS-populated oid trick. I just rolled out Web-to-Lead with a Jquery onsubmit event to populate the org id during submit. But no luck; we are still getting quite a few spam submits. We'll probably have to enable recaptcha...
    – JimG
    Aug 24, 2020 at 11:36

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

  • Even after blocking Lead creation using Validation Rules, a spam script can keep running if they have the WebTo URL with the OrgId. This does count against org limits, i.e., '24-hour maximum of 55,500 for incoming Web-to-Case and Web-to-Lead requests'. Does disabling the Web-to-Lead feature offer any temporary respite?
    – gutsyfella
    Apr 4, 2022 at 23:31
  • 1
    @gutsyfella I honestly don't know. I've always avoided using it for the myriad of problems w2l has. There's not even a place in Salesforce to know how many you've captured for the day or what your remaining allocation is, or at least, I've never seen such a thing. I guess I could set up a script and try it out, see what happens.
    – sfdcfox
    Apr 4, 2022 at 23:44
  • Would appreciate that - I'm trying to block one such ongoing scenario. The web pages containing the W2L have been taken down, however, the script still attempts to post Leads (the Web-to-Lead setting is also disabled). It's possible the form is duplicated and the script is being run against that. Wonder if it's the Leads in SF's Pending Queue attempting to be created but getting blocked by my VR. I was of the opinion that the request is not even sent to the Org if the Web-to-Lead setting is disabled (Enable your organization to receive online leads).
    – gutsyfella
    Apr 5, 2022 at 0:04

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

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


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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .