How to stop spam submissions (without wrecking your forms)

Spam submissions: define the problem before you “solve” it

“Spam submissions” usually means one of three things:

1. Junk leads hitting contact/demo forms
2. Automated sign-ups inflating your metrics and draining ops time
3. Noisy API/form abuse that burns email/SMS budget and clogs queues

OWASP classifies this kind of thing as automated threats—bots abusing normal functionality at scale rather than exploiting a single bug (OWASP Automated Threats). That framing matters, because it pushes you towards systems that can handle volume, not just one-off tricks.

Why “just add a CAPTCHA” often isn’t a strategy

A one-size-fits-all challenge can help, but it’s rarely the whole answer. Attackers don’t need to be clever; they need to be persistent.

The more reliable approach is to treat spam prevention as an engineering loop: detect signals, make a decision, and respond in a way that matches the risk.

The model to ship: Detect → Decide → Respond

This is the cleanest way to stop spam submissions without turning your forms into a science project.

1. Detect signals (velocity, browser integrity, network reputation, behavioural patterns).
2. Decide risk (score or bucket) for this submission.
3. Respond with an outcome that matches the risk.

This is consistent with how score-based verification is designed to be used (for example, reCAPTCHA v3 returns a score and expects server-side action based on risk) (reCAPTCHA v3 docs).

Pick a simple policy: Allow / Step-up / Block

If your team can agree on one thing, make it this. It’s easy for product owners to reason about and easy for developers to implement.

1. Allow: low-risk submissions go straight through.
2. Step-up: medium-risk submissions need extra proof (verification, confirmation, or an additional check).
3. Block / throttle: high-risk submissions are denied or slowed until the attack stops being profitable.

Where to implement spam prevention (hint: not only in the UI)

Bots love front-end-only defences because they can ignore them. Protect the POST handler / API route that actually creates the lead, sends the email, or writes to the database.

Do still add client-side checks for user experience, but assume anything in the browser can be bypassed.

Practical controls that stop spam submissions

You don’t need 27 rules. You need a small set of controls that cover different failure modes.

1) Per-endpoint rate limiting

Rate limiting is foundational for anything that can be abused cheaply. For APIs and form endpoints, standard practice is to return HTTP 429 Too Many Requests when the client exceeds your limits (MDN on 429).

Make it per endpoint:

1. POST /contact should have different thresholds from POST /signup
2. bursts (seconds) and drip attacks (hours) need different windows

2) Risk-based verification (challenge only when needed)

Instead of challenging everyone, score submissions and only step up the suspicious slice. This keeps your funnel moving while still giving you a lever when attacks ramp up.

If you’re using a widget-based approach, Turnstile is positioned as a user-friendly, privacy-preserving CAPTCHA alternative (Cloudflare Turnstile announcement). Whatever you choose, make sure you verify tokens server-side.

3) Server-side input validation and payload limits

Spam bots will happily send garbage: huge payloads, odd encodings, and fields you didn’t ask for.

OWASP’s advice is simple: client-side validation can be bypassed, so you must validate on the server (OWASP Input Validation Cheat Sheet). Add sensible size limits too (body size, field lengths, attachment rules).

4) Make valuable outcomes conditional

A product trick that works surprisingly well: accept the submission, but delay the reward.

Concrete examples:

1. Newsletter: store the request, but only activate on email confirmation.
2. Demo/contact: only create a CRM lead after verification (or only notify sales after confirmation).
3. Free trial: create the account, but issue API keys/credits after a higher-confidence check.

This keeps the UX smooth while removing the attacker’s “instant payoff”.

5) Instrument the funnel (so you can actually improve it)

If you can’t measure it, you’ll either over-block or under-protect.

Track:

1. submission volume per endpoint
2. step-up rate (% of users asked for extra proof)
3. pass/fail rate of verification
4. time-to-complete (UX impact)
5. confirmed spam rate (your real north star)

A quick implementation checklist (copy into a sprint ticket)

1. Put a risk gate on the server endpoint (e.g. POST /contact).
2. Implement Allow / Step-up / Block responses.
3. Add per-endpoint rate limiting with clear thresholds.
4. Verify any tokens server-side and bind them to an action.
5. Add server-side validation, payload limits, and logging.
6. Add dashboards for step-up rate, conversion impact, confirmed spam.

Example: stopping “Request a demo” spam without killing your leads

Say your demo form is being flooded with nonsense.

1. Allow: normal browsers with normal behaviour create a lead instantly.
2. Step-up: suspicious sessions (bursty attempts, odd browser signals, data-centre networks) must pass verification or confirm email before a lead is created.
3. Block/throttle: repeated high-risk attempts get 429s and are slowed.

The key is you’re protecting the creation of value (a sales-ready lead), not just adding friction at the top of the page.

Where Humans Only fits

Humans Only is built to stop spam submissions with risk-based verification that stays pleasant for real users. It’s fast (typically under 2 seconds), privacy-first (zero tracking), easy to drop in, and comes with real-time analytics so you can see exactly which forms are being targeted.

If you want spam form protection that product owners can tune and developers can operate without duct tape, Humans Only gives you a clean Detect → Decide → Respond loop.

Bottom line

To stop spam submissions reliably, protect the server endpoint, use per-form rate limits, and adopt a risk-based allow/step-up/block policy. Measure success as fewer successful spam submissions, not “how many requests we blocked”.