If you create and maintain a webform, you will need to consider how unscrupulous marketers will abuse that webform to generate unsolicited messages, aka spam.
Site Builder provides some defensive tools that you can leverage to improve the security of your webform. Unfortunately, none of these tools are 100% effective. Each spam mitigation strategy has pros and cons. We need to set up multiple defense layers and introduce new tools as the spammers devise ways to bypass these protections.
Failure to protect your webform may result in a flood of spam to your inbox or – even worse – it could damage the reputation of Princeton University's email servers, causing legitimate princeton.edu emails to end up incorrectly sorted into spam or junk folders.
Locking down your webform so that only authenticated users can submit data is the most effective method to prevent spam submissions. Unfortunately, this method is not an option if the audience for your webform extends beyond the Princeton University community.
A webform protected behind a log-in requirement may not need any of the additional layers of protection listed below.
Close Down Inactive Forms
If your webform has a submission deadline, make sure you change your form's status from open to closed after the deadline has passed. If you will need the form again in the future, you can easily open the form back up for new submissions. You can also use the Scheduled form status setting to configure the date and time for your form to open and close.
Some form submission bots may not be sophisticated enough to navigate a multipage form. You might even have some answers for a multi-option form question that lead to a page with more information instead of proceeding with the form. The “Getting help with accessibility” form is a great example of a multipage, branching webform.
Allowing the form submitter to receive a copy of their form submission by email is a nice feature; however, because of spammer abuse, we no longer allow this feature unless the webform is restricted to authenticated users only. Webforms configured this way can operate as an "open mail relay", allowing spammers to generate spam email to anyone.
The following is an example of a vulnerable form.
- A webform asks the submitter to provide an email address.
- The webform is configured to automatically send a confirmation email with the submitted values to that provided email address.
- The spammer fills in that email field with the email address of a spam target.
- The spammer fills in the other fields with links to spam websites or other scam information.
- Because the form is on a trusted Princeton University web server that uses a trusted email server, the generated email receives a positive reputation score.
- Because of that reputation score, the spam message will go directly to the spam target's inbox instead of a junk folder.
- The spammer uses a script to repeat this over and over again with hundreds of spam target addresses.
If you want to show the results of a form's submission to the submitter, configure the confirmation page to display those values instead of emailing the submitted values to the submitter.
Contact us to request an exemption to this rule for a specific Webform.
Eliminate All Emails
Even if a webform can't be used as an email relay, a spammer may still choose to abuse a webform and excessively submit the form. Very often, one or more form administrators will receive an email each time the form is submitted. If a spammer is attacking the form, these emails can be worrisome and may contain offensive language. If a form is under attack, a short term fix may be for the site admin to go into the webform configuration and disable all emails. Any form submissions would still go into the database for the site and can be viewed by the form administrators on the webform results tab.
CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart) used to be a reliable method to prevent automated scripts from filling out and submitting forms. The simplest CAPTCHAs require answering a math problem or identifying visually distorted letters. More advanced CAPTCHAs, like reCAPTCHA, require a form submitter to identify objects in an array of images, such as taxis, traffic lights, stop signs, or crosswalks. While reCAPTCHA does have an accessible fallback for non-sighted users, these CAPTCHAs can diminish the user experience for most users.
Unfortunately, some automated form submission tools are now able to solve CAPTCHAs more quickly and efficiently than a human. Tools powered by machine learning can even solve the image based CAPTCHAs, such as reCAPTCHA. For now, we still recommend reCAPTCHA as an additional layer of defense. As automated CAPTCHA solvers become more widespread, we may reevaluate this strategy.
Site Builder has the Honeypot module active across all web forms on the platform. The Honeypot A collection of features or functionality that can be enabled on sites. WDS has made several optional modules available to site administrators to enable on their site. For example, the "News" module enables the News content type and provide a News List Block for displaying news on a page. uses the honeypot and timestamp methods to deter bots from successfully submitting webforms. The honeypot method places a hidden field on the form. A bot will generally fill out all fields on the form, but if it fills out the hidden field, the form submission is rejected. The timestamp method assumes that a legitimately filled in form will take longer than a specified time to fill out, and if the bot fills out and submits the form too quickly, the submission is rejected.
IP Address Banning
WDS has set up a method to ban individual IP addresses across the platform. This method might be effective if we are able to interrupt an in-progress attack. However, the spammer will often just switch to a different IP address and try again.
The Drupal Webform module includes a setting for each form to limit the number of form submissions from a particular user. For anonymous form submitters, it sets a session cookie to identify the user. Unfortunately, a form submitter just has to start a new session or turn off cookies to bypass this restriction.