Prevent fake signups: a practical playbook for product owners and developers

Fake signups are rarely “just noise”. They inflate your top-of-funnel, drain email/SMS spend, pollute analytics, and create a handy launchpad for spam, referral abuse, and trial farming.

For product owners and developers, the goal isn’t “add a CAPTCHA”. It’s prevent fake signups in a way you can operate: measurable, adaptable, and friendly to real users.

What we mean by “fake signups” (and why OWASP calls it a real threat)

OWASP categorises bulk automated registration as OAT-019: Account Creation — attackers creating accounts through your normal sign-up flow at scale (OWASP OAT-019).

That definition matters because it points you to the right defences: controls that manage interaction frequency and workflow integrity, not just a widget on the front end.

Primary and secondary keywords (so the post stays tight)

1. Primary keywords: prevent fake signups, fake signup prevention
2. Secondary keywords: bot signup protection, fake account creation, risk-based verification, rate limiting

The practical model: Detect → Decide → Respond

If you want fake signup prevention that survives modern automation (headless browsers, proxies, human-assisted flows), use a simple loop:

1. Detect signals (network, browser integrity, behaviour, velocity).
2. Decide risk (score or bucket the attempt).
3. Respond with an outcome that matches the risk.

This is the same operating idea that score-based approaches popularised. For example, reCAPTCHA v3 returns a score so you can take different actions per interaction and verify the result server-side (reCAPTCHA v3 docs). Brand aside, the point is: don’t treat sign-up as a single yes/no gate.

Where to defend: protect POST /signup, not the UI

Bots are happy to skip your front end entirely. If your controls only live in the browser, you’re defending the wrong surface.

Put your bot signup protection where the account is actually created:

1. Gate POST /signup (or your equivalent) with a server-side decision.
2. Validate any verification token on the backend.
3. Log outcomes (allow/step-up/block) with enough context to debug.

Controls that actually prevent fake signups (without guesswork)

Here’s what tends to work in real products, especially in combination.

1) Rate limiting that matches account creation patterns

Rate limiting is foundational for fake signup prevention. NIST’s digital identity guidance explicitly calls for rate limiting in the context of authentication attempts (NIST SP 800-63B). Sign-up isn’t login, but the principle holds: limit interaction frequency on high-value endpoints.

Make it practical by rate limiting on: - IP and ASN (to handle proxy rotation better) - device/session/browser profile (when you can) - identifier velocity (email/phone), with care for shared domains - rolling windows (burst limits in minutes + slow-burn limits over hours)

2) Risk-based verification (challenge only the suspicious slice)

Good bot signup protection doesn’t treat every visitor like a suspect. You want the majority of humans to glide through.

Risk-based verification means: - Low risk → create the account normally - Medium risk → step-up (extra verification or reduced initial privileges) - High risk → block or throttle

This “allow / step-up / block” policy is easy to explain, easy to measure, and hard to mess up in production.

3) Behaviour and workflow integrity checks

OWASP highlights “improper enforcement of behavioural workflow” as part of the account creation threat model (OWASP OAT-019). In plain terms: bots are often too consistent.

Signals that help: - impossibly fast completion times - identical field timing across many signups - repeated navigation paths (same sequence, same pauses) - browser integrity anomalies (missing APIs, inconsistent headers)

Use these as inputs to a score, not as brittle one-off rules.

4) “No value until verified” product decisions

This is the highest ROI move for product owners: make fresh accounts cheap, and verified accounts valuable.

Concrete examples: - Don’t issue API keys, trial credits, or export access until email verification. - Delay posting/DMs until basic reputation (verified email + account age + normal behaviour). - For referral programmes, only pay out after a downstream action (activation milestone, purchase, retained usage).

You’ll prevent fake signups by removing the incentive to automate them.

5) Keep an eye on your email step (it’s part of the attack surface)

Attackers often funnel fake signups into disposable inboxes or addresses that never complete verification.

Operationally, focus on: - disposable/throwaway domain detection (as a risk signal, not a blanket ban) - sending limits and bounce rates (protect deliverability) - delaying costly sends (welcome sequences, invitations) until verification

This is less glamorous than “anti-bot AI”, but it saves real money.

A simple policy you can ship this sprint

If you want a plan that’s actually deliverable, ship this:

1. Add a server-side risk gate to POST /signup.
2. Implement Allow / Step-up / Block outcomes.
3. Add endpoint-specific rate limiting.
4. Bind verification tokens to the signup action and validate them server-side.
5. Instrument the funnel and review weekly.

Track: - sign-up conversion rate (overall and by risk band) - step-up rate - verification pass/fail rate - time-to-complete sign-up - confirmed fake accounts per day (your real north star)

Two quick examples (what this looks like in practice)

Example 1: SaaS free trial abuse You see 400 “new users” a day, but activation stays flat.

1. Allow most signups.
2. Step-up on data-centre networks + high velocity + automation fingerprints.
3. Require email verification before provisioning trial credits or API keys.
4. Throttle repeated attempts per network/device cluster.

Example 2: Marketplace spam accounts Attackers create accounts to message users or post links.

1. Keep sign-up simple.
2. Tighten controls on first message/first listing (step-up suspicious accounts).
3. Restrict risky actions until verification + basic reputation.

Same principle, different “value action”.

Where Humans Only fits

Humans Only is built to prevent fake signups with risk-based verification that stays pleasant for real users and painful for automation.

It’s designed to be: - Fast (typically under 2 seconds) - Privacy-first (zero tracking) - Easy to integrate (drop-in) - Measurable (real-time analytics you can tune)

If your current approach is “CAPTCHA and hope”, upgrading to a risk gate + clear outcomes is the move that actually scales.

Bottom line

To prevent fake signups, defend the signup endpoint, rate limit with intent, use risk-based verification, and design your product so brand-new accounts don’t instantly unlock value.

That’s how you Stop Bots, Welcome Humans — without turning sign-up into a security project.