Invisible reCAPTCHA and Avoiding Form Spam Submissions

Slate forms use the invisible reCAPTCHA feature that works automatically "behind the scenes" without requiring user interactions (such as clicking "I am not a robot").

In addition to the invisible reCAPTCHA feature, Slate also uses submission-rate limiting for forms to prevent abuse, particularly to prevent confirmation emails from being generated by bot submissions. Emails triggered by the submission of a form are based upon the Form Communications in Slate, and they depend on the values submitted as part of the HTTP POST request from the browser. Nulling (blanking out) the form values as part of the request results in no email being sent by Slate, because the {sys-email} merge field is blank.

Avoiding Spam Submissions

Completely avoiding these types of form submissions is difficult, since bad actors are constantly adjusting their attacks and developing workarounds to foil existing mitigation features. However, there are several simple approaches that might help:

  • One technique is to place a Submission Condition filter on the form to look for NOT [name like "http" or "?"] (only those with a name that does not look like "http" or "?" can submit the form).
  • Additionally, leaving generic message errors caught by this filter (for example, "You are not permitted to submit this form at this time."), can avoid giving insight about the countermeasure to the bad actor.

Deleting Spam Records

If you would like to remove known spam records from your database, you can create a retention policy, provided that you can filter down to the person records to be removed (for example, filtering on the name like "?" or on an interaction, you might place on those records).

For information on managing retention policies, refer to the Retention Policy Editor Knowledge Base article.

Was this article helpful?
1 out of 2 found this helpful