How to Protect a Website Against Form Spam and Malicious Bots
If you’ve started receiving nonsensical messages, suspicious offers, or obviously auto-generated content through your contact form, you’re probably dealing with spam bots. Forms are a common target for bots, and spam can quickly bury genuine enquiries from customers. In this article, we’ll look at ways to protect your forms effectively.
Why are you getting spam through your contact form?
Spam is not usually submitted manually by people, but by automated programs. A bot can find a form on a website, fill in its fields, and submit it repeatedly. Some automated scripts can even bypass the user interface entirely and send requests directly to the endpoint where the website processes the form.
That’s why a simple maths question or puzzle designed to verify that the user is human is not enough. It is also important to validate the request when it is processed on the server. This is where the website can verify whether the request has passed anti-bot protection and whether it should be accepted at all.
How to protect forms against spam and bots
There are several ways to protect forms against spam, whether by using alternative technologies that serve a similar purpose or by adding different layers of protection.
For light spam, a simple measure may be enough. For more intense automated spam, however, it is often better to combine several layers. Years of established security practice show that relying on a single protection mechanism is not sufficient. Bots are constantly evolving, and protection needs to evolve with them — ideally automatically.
1. Google reCAPTCHA
Google reCAPTCHA helps distinguish a legitimate visitor from a bot. When it detects automated activity, it can classify the interaction as risky.
This does not always mean the familiar challenges that ask users to select images of cars or traffic lights. For example, reCAPTCHA v3 works without a traditional challenge and assigns individual interactions a score based on how likely they are to have been performed by a bot rather than a person.
The website can then use this score to decide how to handle user actions, including form submissions. Correct implementation is essential.
Protection does not end with adding reCAPTCHA to the visible part of the form. After the interaction, reCAPTCHA generates a token that the website must also verify on the server side. The form is then protected in two ways:
- Bot detection in the browser, which assigns each visitor a score based on how suspicious their activity appears to be.
- Server-side request verification, which checks whether the user actually went through the form and verifies the resulting score. This helps prevent bots from bypassing the user interface altogether, which is a common automation technique.
2. Cloudflare Turnstile
Cloudflare Turnstile is an alternative solution that can be used to protect forms against automated submissions and spam.
It is designed as an alternative to traditional CAPTCHA challenges. In some cases, however, requiring a small amount of user interaction can still be useful for determining whether the visitor is a bot. In so-called Managed mode, Cloudflare can decide based on the situation whether to show the user a simple checkbox or no visible challenge at all.
This is the recommended setting, although it can be changed if you prefer the protection to remain completely invisible and do not want even a checkbox, without a puzzle, to appear for some users.
As with reCAPTCHA, however, the server-side part of the protection is essential. Just like the alternative mentioned above, Turnstile generates a token that should be verified on the server. If server-side verification is omitted, the implementation is ineffective because a bot can bypass the protection mechanism.
3. Honeypot
A honeypot is a simpler form of protection that can work without requiring any interaction from the user. An extra field intended only to catch bots is added to the form, for example a hidden field called testingBot. A normal visitor does not see it and therefore leaves it empty. A simple bot that automatically fills in every available field, however, may populate it. The website can then treat the submission as suspicious and discard it.
The advantage of a honeypot is that it does not inconvenience legitimate visitors in any way. However, it should not be treated as the only form of protection, because more sophisticated bots can detect these kinds of traps very easily.
It therefore makes more sense as a discreet supplementary layer alongside other measures. It is generally optional and is becoming less effective on its own.
4. Rate limiting
Rate limiting restricts how many times a particular visitor can submit a form within a given period. If, for example, dozens or hundreds of submissions come from a single IP address within a short interval, the website can temporarily block further attempts. The restriction can also be applied directly to the URL endpoint used to communicate with the server and process the form.
Rate limiting is especially useful against bots that try to submit a form in large volumes. It is one of the basic protection mechanisms for preventing automated systems from making excessive requests to perform an action, such as submitting a form.
However, it is not a complete anti-spam solution. A bot may still get one, two, or three submissions through before the limit is triggered. Rate limiting is therefore better used as a supplementary safeguard alongside reCAPTCHA or Turnstile. The idea is that if those protections happen to fail, rate limiting still reduces the number of successful attempts and helps prevent a bot from flooding your entire email inbox with spam.
How to stop spam once and for all
The foundation of your protection should be reCAPTCHA or Cloudflare Turnstile. If a smooth user experience is the priority, choose a solution that does not necessarily require users to complete a traditional image-based CAPTCHA, such as reCAPTCHA v3 or an appropriate Turnstile mode.
For simple automated spam, a honeypot can help, ideally as an additional layer of protection.
If the form is receiving a large number of repeated submissions, it is also worth adding rate limiting. If spam continues despite the existing protection, we recommend combining several mechanisms instead of relying on just one. This layered approach is generally more resilient against different forms of automated abuse.
Tip: Do not rely on a single protection method. You can layer your form security depending on the volume and type of attacks you are dealing with. A well-configured anti-spam setup leaves bots with no easy way through at any stage.
Conclusion
Spam from contact forms can be significantly reduced with properly configured bot protection. For a typical website, you can start with reCAPTCHA or Cloudflare Turnstile and add a honeypot or rate limiting as needed. Ideally, however, your protection should cover every layer.
If you are still receiving spam, check whether the form uses any anti-bot protection at all, which solution has been implemented, and whether that protection is also verified on the server side. With both reCAPTCHA and Turnstile, server-side token verification is an important part of a correct implementation.
If you are not sure whether your form is properly protected against spam, we can review its security and existing anti-spam implementation and recommend a suitable solution for your website.
I want help with anti-spam protection for my forms
Frequently asked questions about contact form security
Yes. CAPTCHA can significantly reduce spam, but on its own it may not stop every type of spam attack. It is important to combine CAPTCHA with server-side verification, and if spam persists, using several layers of protection can help.
Not always. For example, reCAPTCHA v3 can assess the likelihood that a visitor is a bot in the background, without requiring the user to complete a traditional image-based challenge.
Yes. Turnstile is Cloudflare’s anti-bot solution and can also be used to protect web forms. Depending on the selected mode and assessed risk, verification can take place without affecting the user experience at all or may involve a simple checkbox.
No. With both solutions, it is important for the server to verify the token generated during the user verification process. Simply embedding the protection mechanism in the form within the browser does not necessarily provide complete protection.
For very simple spam, a honeypot may catch some automated submissions, but it should not be considered a universal replacement for anti-bot protection. It is more useful as a discreet additional layer of security.
It depends on the solution you choose and how it is configured. Modern solutions can perform verification without traditional “Are you a robot?” CAPTCHA challenges, so legitimate visitors do not necessarily have to be interrupted every time they submit a form.
It can help significantly, especially when a bot is sending a large number of messages within a short period. Rate limiting restricts the number of submissions allowed within a specified period of time.
The most likely reasons are insufficient configuration, missing server-side verification, or an unsuitable type of protection. We recommend implementing protection at every stage, from filling in the form through to its final submission and processing.
Definitely not. Anti-bot protection is commonly added to existing forms. Some modifications to the form are required, but this does not mean rebuilding the entire functionality from scratch.