List bombing: protective measures
Recommended Protective Measures
If you've identified a list bombing incident, multiple solutions are available. Determine when the attack began and review or remove all recipients (even DOI-confirmed) added after that time.
First, remove all registration forms from your web servers. Indexed or bot-crawled form URLs will continue to be attacked even if you add security measures, attackers adapt.
For new or updated forms, avoid reusing the same URL or web server path. Also set the form pages to noindex, nofollow to prevent web crawlers from indexing them.
This is the fastest and most secure way to stop attacks and verify whether your API credentials were compromised or whether the suspected form is truly being targeted. Note that older signup forms may still exist online and could still be connected to your campaigns.
Additionally, we recommend the following measures:
- Implement CSRF Tokens. CSRF tokens (Cross-Site Request Forgery) prevent external sites or bots from submitting the form without loading the real page. The server accepts requests only with a valid, hidden CSRF token field generated upon page load.
- Restrict input fields for content. Many fields like name or first name are vulnerable to URL input. Limit character sets (e.g., block special characters or dots). While not foolproof, it makes attacks less attractive.
- Integrate a honeypot field. A honeypot is an invisible form field for humans but visible to bots. If the field is filled, the submission likely came from a bot. See Integrating Honeypots (below).
- Use non-standard field names in HTML. Bots scan for typical field names. Use creative naming like {}First_Banana, Last_Apple, Em_Orange{} instead of first name, last name, and email. Implement a CAPTCHA. CAPTCHAs distinguish humans from bots. Many GDPR-compliant providers offer various solutions.
- Measure form submission time. Add a field with a timestamp or key upon page load. Humans take minutes to fill forms; bots, only seconds. If submission is too fast, cancel the process.
- Add IP rate-limiting. Limit how many times the same IP address can submit a form in a given time. Define acceptable form inputs. Block special characters, URLs, or HTML tags, or routinely sanitize new entries. Bots might insert harmful links that could end up in your emails.
- Implement JavaScript tokens. A JS token is a client-side value generated only when JavaScript is active. The server checks for valid tokens based on session/IP; invalid tokens result in rejection.
User-Agent Checks are a simple but effective way to distinguish bots from real users based on the User-Agent header sent with HTTP requests.
Important
There is no such thing as 100% protection. Each of the measures listed contributes to better security. Which ones you implement is up to you — but we recommend combining several for optimal effect.
Integrate Honeypots
You can integrate honeypot fields in registration forms as follows:
<input type="email" name="email-confirmation-field1" class="hidden" placeholder="Your email address" required="required" autocomplete="off"> <!-- Visible email field for recipient -->
<input type="email" name="email-field1" class="required" placeholder="Your email address" id="required" autocomplete="off"> <!-- Honeypot field -->
<input type="text" name="birthday-field1" class="optional" autocomplete="off"> <!-- Honeypot field -->
<input type="text" name="name-field1" class="required" autocomplete="off"> <!-- Honeypot field -->
<input type="text" name="city-field1" class="optional" autocomplete="off"> <!-- Honeypot field -->class="hidden". Adjust your CSS so this class is visible.
autocomplete="off". Prevents browsers from autofilling fields. Not all browsers support this reliably, so use non-standard field names like birthday-field1.
Adjust your CSS so all other classes and IDs are not visible. Use:
visibility: none; display: none; width: 0px; height: 0px;