Protecting a Drupal 7 website against spam


From my own experiences, here are several anti-spam techniques and configuration suggestions for protecting Drupal deployments. It is safe to apply all these in combination.

Drupal core

It is easy to overlook relevant settings and permissions available within Drupal as a first line of defence:

Account registration policy

The system can be configured to allow only administrators to register user accounts, or require account registrations to be approved by an administrator. These options can be found at Account settings: Registration and cancellation (/admin/config/people/accounts).

Comment moderation

The Skip comment approval permission (/admin/people/permissions) is another method of control. When not checked for a role (e.g. anonymous user), comments submitted by members of that role are accepted, but remain unapproved/unpublished, essentially placing them in a moderation queue.

An administrator - or user of a role with appropriate permissions - would need to visit /admin/content/comment/approval and approve/publish the comment or delete it from the system. While this does not prevent the receipt of spam, it does prevent its publication as content.

Drupal modules

The following contributed (non-core) modules for Drupal provide useful features for spam prevention or mitigation:

User restrictions

Project page:

The User restrictions module prevents usage of specific usernames or e-mail addresses in user accounts. For example, a deny rule with an e-mail mask of would block both logins of existing accounts and account registrations involving addresses.

Suggestion: Add e-mail masks for some of the common spammer domains listed at Stop Forum Spam. Other suggested domains include (issue #2397911) and those belonging to disposable e-mail services (such as


Project page:

The Spambot module protects the user registration form by querying a visitor's IP address, username and/or e-mail address for existence in the Stop Forum Spam database. If listed, the registration is rejected, preventing account creation.

Spammer criteria is configurable (e.g. at least five reports of an e-mail address), along with the maintenance of whitelists, scanning of existing accounts and reporting of spammers. Delaying rejected registration requests is also available to slow down repeated attempts.

Suggestion: Protect the user registration form, delay rejected registration requests for 10 seconds, and report node/comment spam to Stop Forum Spam prior to unpublishing or deleting (API key required).


Project page:

The Honeypot module adds a field to one or more forms - such as the user registration form - which is hidden from display to humans (through cascading style sheets), but not from spam bots. If any value for this field is supplied, the form submission is rejected.

Honeypot protection can be applied to registration, password reset, node and comment forms, and enabled on specific forms via code. Honeypot can also operate as an event trigger for other modules.

Suggestion: After also installing the Rules module, define a reaction rule to block IP addresses of visitors rejected by Honeypot, enable Honeypot protection on the user login form, and remove blocked IP addresses occasionally. See the following sections for details.

Protecting the user login form

For sites receiving continual spammer login attempts, enable Honeypot protection on the user login form. This currently isn't possible through Honeypot's administration settings (issue #2469371), but can be added through the hook_form_alter() function.

For example, within a theme's template.php file:

function THEMENAME_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id == 'user_login') {
    honeypot_add_form_protection($form, $form_state, array('honeypot', 'time_restriction'));

Blocking spammers automatically

When Honeypot is combined with the Rules module, an effective method of spammer detection and automated blacklisting becomes available.

The following reaction rule can be imported to block a visitor's IP address when a form submission is rejected by Honeypot:

{ "rules_block_honeypot_rejects" : {
    "LABEL" : "Block users rejected by Honeypot",
    "PLUGIN" : "reaction rule",
    "WEIGHT" : "-1",
    "OWNER" : "rules",
    "TAGS" : [ "block", "honeypot" ],
    "REQUIRES" : [ "rules", "honeypot" ],
    "ON" : { "honeypot_reject" : [] },
    "DO" : [ { "block_ip" : [] } ]

Be aware that blocked IP addresses do not expire, remaining in Blocked IP addresses (/admin/config/people/ip-blocking) until removed by an administrator. Consider purging blocked IP addresses at regular intervals (e.g. once a week) through the SQL statement DELETE FROM blocked_ips;, called using a database shell in a cron job.

Service providers

Cloudflare: IP Firewall

Cloudflare is a content distribution network. Its IP Firewall feature provides options to challenge countries or block/challenge IP addresses when accessing Cloudflare-powered sites.

Challenging a country requires visitors within that country to solve a CAPTCHA before site access is granted. This provides the first barrier to entry for spam bots in specific countries, while still allowing human residents to access site content. IP Firewall is available at all pricing plan levels, including Cloudflare Free.

It is obviously not recommended to challenge countries comprising the majority of a site's audience. If site content is to be syndicated on social media services (e.g. Facebook), I recommend not challenging the United States, as this may interfere with crawlers/scrapers operated by those services (such as Facebook Crawler).

Suggestion: With the exception of United States mentioned above, challenge some of (or all) the countries listed within the Spamhaus Top 10 Worst Countries list. Your mileage may vary, but challenging visitors from China (country code CN), Russia (code RU) and Ukraine (code UA) can result in a significant reduction of spam attempts.

Last updated: 
2016-10-15 12:56

Add new comment