Supabase fraud prevention

“

TL;DR

• 1,400 weekend signups, no ads running, Turnstile on the form, and CAPTCHA stopped none of it.
• Disposable inboxes, plus-addressed Gmail variants, tight time clusters: the classic bot signup signature.
• Supabase auth is solid; the gap is what Supabase ships in the box versus what actually stops bot signups in 2026.
• The data fake accounts leave behind is a bigger problem than the accounts themselves.
• The fix is architectural: signup-time risk scoring in the same first-party pipeline.

I shipped a Supabase B2C waitlist last year, opened the dashboard one Monday, and found 1,400 new signups from a weekend I had not run a single ad. Felt great for about four minutes. Then I sorted by email domain and watched my stomach drop. Disposable inboxes, plus-addressed variants of the same three Gmail accounts, and a tidy cluster of signups all firing within the same eleven-minute window.

That waitlist had Turnstile on it. CAPTCHA did not stop any of it.

This is not a "Supabase is insecure" post. Supabase auth is solid. This is a post about the gap between what Supabase ships in the box and what actually stops bot signups in 2026, and about why the data those fake accounts leave behind is a bigger problem than the accounts themselves. The fix is architectural, SignUp Cops is the part of that architecture Supabase was never built to be. See also best signup fraud detection 2026 and fraud traffic validation.

Here is the honest read of what Supabase gives you, what it does not, and the playbook I would run if I were standing up auth today.

Quick stuff people keep asking

Does Supabase have built-in fraud detection? Not really. Supabase ships CAPTCHA support (Turnstile and hCaptcha), fail2ban-style brute-force protection, and configurable rate limits. Those are abuse controls, not fraud detection. None of them score a signup for risk. None of them know that the account is the 11th from one device.

How do you stop bot signups in Supabase? Layer it. Turnstile at the form, rate limits on the auth endpoints, a disposable-domain block in a Postgres function, plus-address normalization, and a webhook from auth.users to an external scorer that reads device and IP signals. Supabase covers the first two. The rest is on you.

How do I add CAPTCHA to Supabase auth? Enable it under Authentication settings, pick Turnstile or hCaptcha, drop the widget on your form, pass the token in the captchaToken option on signUp. It is a 20-minute job. Just do not expect it to carry the whole load. CAPTCHA solve rates by bots run 90% and up now.

How do I block disposable emails in Supabase? There is no native toggle. You write a Postgres function that checks the email domain against a table of known disposable domains, and you call it from a before user created auth hook or a trigger. The hard part is keeping that domain list fresh, because new burner domains appear daily.

Can Supabase rate-limit signups? Yes, the auth rate limits are configurable. The catch: the defaults are generous and a patient attacker tunes their request rate to sit just under your ceiling. Rate limits slow a flood. They do not stop a drip.

How do I detect fake users in Supabase? Not from inside Supabase alone. Supabase stores the user. It does not see the device fingerprint, the IP reputation, or the behavioral timing that separates a human from an agent. You need a signal source outside the database.

Is supabase.auth.signInAnonymously safe? It is useful and it is also an abuse vector. Anonymous signin creates a real row in auth.users with no credential. Bots love it because there is nothing to verify. If you use it, rate-limit it hard, and treat anonymous users as a separate, lower-trust tier until they convert.

What Supabase secures, and the layer it leaves wide open

Supabase secures the database. Row Level Security, JWT handling, brute-force lockout, encrypted storage. That is genuinely strong, and most teams underuse it.

What Supabase does not do is judge whether the human behind a signup is real. That judgment needs three signals Supabase never collects: the device fingerprint, the IP reputation, and the behavioral pattern across multiple signups. A bot farm running 650 fake accounts off one device looks, to Supabase, like 650 ordinary rows. The contamination is invisible at the database layer because the database was never built to see it.

Here is where it stops being an account-hygiene problem and becomes a money problem. PillarlabAI ran a honeypot last year. They put up a signup flow, did light promotion, and let it run. 3,000 signups came in. When they fingerprinted the traffic, 77% of it was fraud. 650 of those accounts traced back to a single device. One machine, 650 identities, all of it sitting in the user table looking legitimate.

Now follow that data downstream. Most teams fire a Meta or Google conversion event on signup. So every one of those 650 fake accounts also fired a "signup" conversion into the ad platforms. Meta took that signal, learned what those "converting users" looked like, and went and found more of them. That is the trap. The bots do not just inflate your user count. They retrain your ad optimization to hunt for more bots. Your cost per real acquisition climbs and the dashboard still shows growth. Garbage in, garbage optimized, garbage out.

Supabase storing the row cleanly is not the same as the row being clean.

The consolidated Supabase fraud playbook

Most guides hand you one piece. Here is the whole stack, in the order I would build it.

1. Turnstile at the form. Enable it, wire captchaToken. It filters the laziest bots and costs nothing. Treat it as the doormat, not the lock.

2. Rate limits on the auth endpoints. Tighten the signup and OTP limits below the generous defaults. This caps the blast radius of a flood.

3. Plus-address normalization in Postgres. A Postgres function that strips the +tag and lowercases the domain before you check uniqueness. [email protected] and [email protected] are one inbox. Normalize so one human cannot mint twenty "unique" accounts.

4. A daily-updated disposable-domain table. A table of burner domains, refreshed by a scheduled job, checked in a before user created hook. Rejects the obvious throwaway inboxes. The freshness of the list is the whole game.

5. A webhook from auth.users to an external fraud scorer. This is the layer Supabase cannot be. On insert, send the signup to a service that reads device fingerprint, IP reputation (residential vs datacenter vs VPN vs proxy vs Tor), and email-domain freshness, and returns a risk verdict. Gate RLS access or downstream provisioning on that verdict.

Steps 1 through 4 are housekeeping. Step 5 is where real bot signups actually get caught, because it is the only step with signals from outside your database.

Where DataCops fits

DataCops is built to be step 5, and to be the thing the other four steps quietly need.

It runs on a first-party architecture on your own subdomain. Practically: the signal collection is not a third-party script that uBlock or Brave blocks 30 to 40% of the time. It is far more resilient than a bolt-on widget, because it is part of your own infrastructure.

SignUp Cops scores the signup at the moment it happens. It reads the IP against a 361.8 billion-plus IP database to tell residential from datacenter from VPN from proxy from Tor, reads the device fingerprint, and surfaces when 650 accounts share one machine. It does not "block" anything in a black-box way. It surfaces the context and hands you the verdict, and you decide what your auth.users webhook does with it.

The part that matters most for the honeypot problem: that same first-party pipeline ships your analytics and your Meta and Google CAPI events. So the fraud verdict and the conversion signal live in one place. A signup flagged as fraud does not have to fire a clean conversion into Meta. You stop training the ad platforms on bots. Two data tiers, separated at the source, before the data ever leaves your infrastructure.

Honest limitations: DataCops is a newer brand than the incumbents, and SOC 2 Type II is still in progress, so a heavily regulated buyer may want to wait for that. The free tier is 2,000 signup verifications a month, which is enough to run a real waitlist and see your actual fraud rate before you pay anything.

Decision guide

• Small project, low signup volume, no ad spend: Turnstile plus rate limits plus a disposable-domain block is fine. Do not over-build.
• Running paid acquisition into a Supabase signup flow: you need step 5. Fake signups are poisoning your CAPI right now.
• Heavy use of signInAnonymously: rate-limit it hard and score conversions, not the anonymous rows.
• Regulated industry, SOC 2 required from day one: shortlist DataCops but confirm the Type II timeline first.
• You just want to know your real fraud rate: run the free tier against live traffic for a month and read the number.

The fake accounts are not the problem you think they are

The 1,400 weekend signups did not cost me a database row. Rows are cheap. They cost me a week of Meta optimization spent learning the shape of a bot, and I did not notice until the cost per real signup had already drifted up.

Supabase will store whatever you send it, cleanly and securely. That is its job. Judging whether the signup is a real human, and keeping that judgment from poisoning everything downstream, was never its job.

So here is the question. Pull your auth.users table, group by device fingerprint and email domain, and look at the clusters. How many of your "users" are actually one machine wearing a lot of hats, and how many ad dollars have you already spent teaching Meta to find more of them?