Fake signups

Stop fake signups without blocking your real users

Fake accounts arrive looking like real ones. FindIP Shield records every signup attempt with a risk score and the network reasons behind it, lets you choose a response per form when you are ready, and gives your server the one check a browser cannot bypass. Start by monitoring; nothing is blocked until you decide.

Monitor my signup flow See a suspicious signup

Free Preview · 10,000 events per site per day · No credit card · Terms apply

Proxy VPN Tor Hosting network Malicious IP IP rotation in session
The problem

Rate limits see bursts. Email checks see domains. Neither sees where a signup came from.

A signup form only knows what the visitor typed. It cannot tell that the connection arrived through a datacenter in another country, that the IP changed twice during the session, or that the same network produced the last forty accounts.

Email checks catch disposable domains and miss plus-addressing. Rate limits catch bursts and miss a slow, patient script. By the time fake accounts show up as a payment problem or a distorted activation chart, they have been in your data for weeks.

The useful question is not whether an IP is bad. It is what happened, which signals explain the risk, and what the least disruptive response would be — and that question has to be answered on your server, not only in the page.

One event, explained

What one of these looks like in Shield

Every visit and form submit is recorded with a score, the reasons behind it, the session around it, and what the page did. A hosting network or a VPN is used legitimately every day; the reasons are there so you can judge, not a verdict on a person.

A recorded eventSample data

signup_attempt

78 · critical

/signup · a moment ago

Why this risk score
  • hosting_networkThe IP belongs to hosting infrastructure rather than a consumer access network.
  • proxy_detectedThe current IP is a known anonymizing proxy.
  • signup_attemptA sensitive action: the reasons above weigh more here than on a page view.
Session
Network
AS64510 · hosting · Netherlands
IP changes in session
2
Pages before the submit
1
Form
signup, discovered automatically
What happened
Shield recommended
challenge
A verdict for your site to use. On its own it stops nothing.
Observed in the page
Challenge failed
This site asks suspicious signups for a Cloudflare Turnstile check. The visitor did not pass it, and the account was never created.
How Shield helps

From the first signup event to a decision you can defend

Five steps, in the order teams actually take them. The first one is the only one you need on day one.

Start by monitoring

Create a free Shield site and install it. Nothing is blocked. Within the hour every signup attempt is on your dashboard with a 0 to 100 score and the reasons behind it.

Read the reasons

Codes such as hosting_network, proxy_detected or vpn_detected, each with a plain sentence, plus the session: pages before the submit, IP or network changes, the form involved.

Add what only you know

Attach a hashed user ID after signup, or look at the account the session created. A VPN alone means little; a VPN plus a rotating network plus a disposable email means more.

Choose a response per form

Watch only, slow it down, ask for a Cloudflare Turnstile check, or stop the submit. Chosen per form, changeable at any time, every outcome recorded next to the recommendation.

Make it stick on your server

Before you create the account, verify the session with your secret key. A browser can be bypassed; the server check is the one that counts. Then review outcomes week by week.

What Shield shows you

The evidence, then the response you choose

Every signup attempt, with its network

Shield records signup_view and signup_attempt events with a 0 to 100 risk score and reason codes such as vpn_detected, hosting_network or proxy_detected. Never the form values, the password or the email.

A response per form, chosen by you

Installing changes nothing. When you are ready, pick the signup form Shield discovered and choose watch only, slow down, a Cloudflare Turnstile check, or stop. Every outcome is recorded next to the recommendation.

A server-side check for the decision that matters

Before you create the account, verify the session from your server with your secret key. That is the one decision a browser cannot bypass.

Setup

Install on your signup flow in three steps

For sites where you can edit the HTML or the application bundle. The same snippet works with React, Next.js, Vue, SvelteKit, Astro or plain HTML; the runnable examples below show each.

Create a Shield site

Sign in, add the domain you control, and pick a privacy mode. You get a public site key; nothing connects until it is on a page.

Add the snippet

Paste one script tag before the closing body tag, or run npm install @findip/shield and call init() with your site key. Auto page and form tracking is on by default.

Watch the first real event

Submit a test on your own form. The event, its risk score and the reasons behind it appear on the site dashboard moments later.

Monitor my signup flow Read the quickstart

Prefer another route? Install through WordPress, Shopify, Google Tag Manager, or connect Cloudflare instead.

In your stack

A client component starts the SDK once; the signup handler sends the Shield session ID to a route handler, which verifies it with the secret key before creating the account. The same shape works for SvelteKit form actions and Astro server pages.

// app/shield.tsx  ('use client')
useEffect(() => { init({ siteKey: process.env.NEXT_PUBLIC_FINDIP_SHIELD_SITE_KEY! }); }, []);

// app/signup/signup-form.tsx — send the session with the signup
await fetch('/api/signup', { method: 'POST',
  body: JSON.stringify({ email, findip_session_id: getSession().sessionId }) });

// app/api/signup/route.ts — the decision that counts
const verdict = await verifyShieldSession(body.findip_session_id, 'signup_attempt');
if (verdict.decision === 'reject') return Response.json({ error: 'signup_declined' }, { status: 403 });
// 'review' (monitor, unknown, or no key yet): create the account and flag it for a look
Runnable Next.js example, with lib/shield-verify.ts

Before </body> on every page. Auto-tracking reports page views and form submits (shape only, never values); data-session-field adds a hidden findip_session input to your forms so your server can verify the session.

<script
  src="https://cdn.findip.net/shield/v1.js"
  data-site-key="pub_your_site_key"
  data-auto-track="true"
  data-privacy-mode="balanced"
  data-session-field="true">
</script>
Runnable plain-HTML example

One POST from your server with the secret key, before the sensitive action. verified tells you the session is real; recommendation is allow, monitor, challenge or block; risk_status unknown means FindIP had no intelligence for that IP, which you treat as monitor, never as safe.

curl -X POST https://shield.findip.net/v1/shield/sessions/verify \
  -H "Authorization: Bearer $FINDIP_SHIELD_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"session_id": "<from the browser or the findip_session field>", "event": "signup_attempt"}'

# → {"verified": true, "risk_status": "available", "risk_score": 78,
#    "recommendation": "challenge", "challenge_passed": false}
Server verification reference

Import the FindIP Shield tag template, paste the public site key, publish. Every risk result is pushed to the dataLayer, so your existing tags and analytics can read it. Server verification still needs your backend.

// what the tag pushes after each scored event
dataLayer.push({ event: 'findip_shield_result', shield_event: 'signup_attempt',
  shield_risk_score: 78, shield_risk_level: 'critical',
  shield_recommendation: 'challenge', shield_reasons: ['hosting_network', 'signup_attempt'] });
Google Tag Manager guide
Boundaries

What a risk score is, and what it is not

An assessment, not proof. A VPN, a hosting network or a changing IP is common for privacy-conscious and corporate users too. Shield explains the reasons so you can decide; it does not pass judgement on a person.
Friction, not a security boundary. Anything decided in the browser can be bypassed by someone who controls it. For decisions that matter, verify the session from your server with your secret key.
Unknown is never safe. Where no intelligence was available the status is unknown. Shield fails open: if a decision does not arrive, the form submits as normal.
Questions

Frequently asked

Not unless you choose to. Privacy-conscious people and corporate networks use VPNs every day. Shield reports the signal and the reason; a score is an assessment, not proof. Most teams watch first, then add a Turnstile check only for the combinations they have seen abuse from — a VPN alone is rarely one of them.

No, and that is the right default. Installing the snippet is monitor only. When you give a form a response it runs in the browser — slow down, Turnstile check, or stop — and fails open if a decision does not arrive. The decision that cannot be bypassed is the verify call your server makes with the secret key before creating the account.

Form attributes and the submit event, never the values. Passwords, emails, phone numbers and payment fields are never sent. How much browser and session context is collected depends on the privacy mode you choose.

Yes. Pass a hashed user ID to the SDK or the dataLayer once the account exists. Shield hashes identifiers in the browser, so a risky session can be traced to an account in your system without Shield holding the raw email.

10,000 events per site per day, no credit card. Beyond the quota events are refused with a 429 and shown as refused; they are never silently dropped as safe. Cloudflare edge decisions have their own, separate limit.
Keep reading

Related

Stop Free Trial Abuse Before the Account Exists VPN and Proxy Signup Detection for Websites Login Abuse Detection: Credential Stuffing Signals FindIP Shield overview Guide: visitor risk scoring for signup and checkout

Start by watching one real flow.

Create a free Shield site, install it, and look at the first real event before you decide on any response.

Monitor my signup flow

Next: create a free Shield site, choose how to install it, and see the first real signup event. Nothing is blocked until you choose a response.

Free Preview · Monitor first · Stop, slow, challenge, or redirect risky submits when you choose