Anti-spam for forms without mandatory CAPTCHA: protection before saving applications and a reason log

What this solution does

Reduced spam in submissions without mandatory CAPTCHA

The module checks form submissions, registrations, and subscriptions on 1C-Bitrix sites. Basic protection works invisibly to the user and does not require connecting to external Google or Yandex services. If a specific form requires enhanced verification, you can enable a puzzle, arithmetic example, logical question, or external CAPTCHA.

Verification is not limited to the moment of email sending. The module can block spam before the submission is saved to the information block. For handlers that bypass standard Bitrix events, separate protection is provided for selected addresses before the page code runs.

Anti-spam module for forms without mandatory CAPTCHA. It filters submissions before saving and maintains a detailed log of block reasons.

Nine customizable checks are available: honeypot fields, fill time, link analysis, suspicious code fragments, stop words, HTML and BBCode tags, automated sending indicators, request frequency, and long messages without Cyrillic characters. Each check can be enabled or disabled individually, and thresholds for time, link counts, and submission frequency can be adjusted to suit the specific site.

Protection operates at various submission stages: mail events from both old and new APIs, standard web forms, user registration, subscription, and infoblock element creation. It includes control over non-standard handlers by verifying POST requests at selected addresses before page processing.

The block log provides clear information: block reason, form name, event time, IP address, and applied filters. Data can be exported in CSV format.

An additional CAPTCHA can be configured by choice: a custom puzzle, example, question, Yandex SmartCaptcha, or Google reCAPTCHA versions v2 and v3.

Settings are isolated for each site within a multisite installation. Checks, forms, lists, and logs remain separate and do not mix between domains.

The verification process is transparent to the user. Visitors fill out forms in the standard way while the module analyzes fields and bot activity indicators in the background without requiring additional actions from them.

Checking for long text without Cyrillic characters does not suit every project. If clients write in other languages, this check can be disabled while keeping other validations active. Settings should be evaluated on actual forms rather than enabling maximum strictness without testing.

Anti-spam for forms without mandatory CAPTCHA: protection before saving submissions and reason logging

Spam can be prevented before a submission is saved to the database. In some scenarios, a form saves the request first and then sends a notification. If only the email sending is blocked, the spam will still remain in the list of submissions.

The module analyzes the creation of an information block element when a form is submitted from the public part of the site. For non-standard components that write data to a custom table without using Bitrix events, you can separately specify a page address or handler and enable checking before its execution.

Address protection is disabled by default. It is configured for specific handlers and requires compatibility verification with the form. For AJAX requests that return data without displaying a page to the user, a silent-only checking mode is provided.

Anti-spam for forms without mandatory CAPTCHA: protection before saving submissions and rejection reason logs

Visible verification is not required for basic module operation. It can be enabled only on problematic forms, avoiding extra steps for all site submissions.

The module remembers forms encountered on website pages. The required form is selected by its id, name, or data-tab-form attribute. A unique key can be assigned to specific forms.

The built-in slider puzzle works without external service keys. Integration with Yandex SmartCaptcha and Google reCAPTCHA requires corresponding keys from these providers. The duration for which a successfully passed check is remembered is configurable.

Rejection logs

The log helps analyze triggers: users can select a period, form, action, or rejection cause, view the IP address, and export results to CSV. Options include logging only rejected submissions or temporarily enabling a log of all checked submissions.

By default, form field values are not saved. If analysis of false positives based on content is required, the administrator can separately enable saving data from rejected submissions. This involves additional storage of user data: enable this feature consciously and configure the retention period. The content of successfully submitted applications is not duplicated by this option.

IP addresses can be masked. Old records are deleted according to the specified retention period. Before transferring the log to a third party, verify exactly what data it contains.

Anti-spam for forms without mandatory CAPTCHA: protection before saving submissions and reason logging

Protection settings are adapted to the specific website. After installation, blocking is not enabled automatically. The administrator selects the target site, activates the required functions, and tests standard submissions. Exceptions can be configured for specific pages and forms. Precise tuning is available via white and black lists of IP addresses and User-Agent strings, an ASN list, and stop words.

If an error is caught by the module during verification, the submission proceeds further. This does not eliminate the need to verify compatibility with your site or monitor false positives. An emergency disable feature is provided that preserves settings, lists, and the log.

Basic protection runs on your server

Silent verification and a custom puzzle do not require the developer's cloud service. The module does not send its own telemetry. External CAPTCHA services are connected only at the website owner's discretion.

For sites behind Cloudflare, a load balancer, or a reverse proxy, IP address determination via trusted proxies is supported. Trust settings must be verified in your environment.

Anti-spam for forms without mandatory CAPTCHA: protection before saving submissions and a reason log

Before deployment, verify compatibility with your template forms, including AJAX requests and forms located within modal windows. Test the submission process using mobile devices, new browser sessions, and data typical of real clients.

Review the reasons for blocks and configure exceptions for specific forms if necessary. If your form handlers do not utilize standard Bitrix events, separate configuration for address protection may be required.

This module is designed to protect forms and selected handlers. It does not replace comprehensive security measures such as DDoS protection, firewall functionality, vulnerability scanning, or systems that block all scrapers.

Start with the demo version. Install the module, enable basic protection, verify form functionality, and review the event log. Detailed setup instructions are available in the Installation section.

If “Anti-spam for forms without mandatory CAPTCHA: protection before saving applications and a reason log” fits the task, General iT can install the module, configure it and verify the result in the project.