Don't Wait Until You're Fleeced: The Anti-Fraud Playbook for Vibe-Coded Projects

Three Real Nightmares: You May Be Running Naked Without Knowing It

Nightmare one: you issue a $7 no-threshold coupon for user acquisition. At 3 AM a script farm finds it; by morning there are 2,000 new "users" in your dashboard, the coupon pool is drained, and real users arrive to find nothing left. Your acquisition budget just became someone else's inventory.

Nightmare two: every account gets 100 free AI calls a month, and you hope the free tier converts to paid. One day the bill looks wrong. The logs show 300 accounts sharing one request fingerprint, maxing out quotas around the clock — your model bill is subsidizing someone else's business.

Nightmare three: you run a paid knowledge community. Someone scripts thousands of sock-puppet accounts to upvote themselves and flood the trending feed. Real users see nothing but astroturfed content and churn by day three.

All three share one trait: nothing at the login layer stopped them. CAPTCHAs, SMS rate limits, IP bans — those all sit at the "front door," while the fraud happens at the "business" layer. Attackers long ago stopped fighting your CAPTCHA; they fight your business rules instead. They understand when your coupons drop, how quotas are calculated, and how your leaderboard ranks — often better than your own PM does.

So this guide covers exactly one thing: business-layer anti-fraud. Not web security (that's SQL injection and XSS territory), not login brute-force protection (that's the SMS OTP rate-limiting playbook), and not supply-chain security (dependency poisoning defense). The site already has dedicated guides for those; the boundary section at the end links them so we don't reinvent wheels.

Know Your Enemy: Four Fraud Profiles

Before building anything, classify the enemy. Vibe-coded projects face four recurring fraud types. Each has different motives, different tradecraft, and different defenses. Conflating them is the first trap many indie developers fall into.

Type 1: Mass Registration / Bonus Abuse

The target is your "new user perks": coupons, free quotas, referral rewards, trial memberships. The tradecraft is scripted registration plus burner-phone SMS services plus proxy IP pools. The signatures are obvious once you look: registrations clustered in time, near-identical behavior sequences (register → claim coupon → order → cash out, in one breath), and highly similar device fingerprints.

The cruel part: this fraud is raised by your own growth strategy. The juicier the coupon and the lower the barrier, the faster the farms arrive. Plenty of vibe projects die on the "growth hacking" slide — beautiful acquisition numbers for three months, then the discovery that it was all bonus abusers.

Type 2: Fake Transactions / Order Brushing

The target is your "trust system": sales numbers, ratings, rankings, recommendation weight. The tradecraft is self-dealing, reciprocal brushing, and purchased reviews. E-commerce, content platforms, and freelance marketplaces are the hardest hit. Signatures: buyer and seller tightly linked (same device, same IP block, closed money loop), templated review text, and abnormal transaction timing (a burst of orders at 3 AM).

Type 3: Content Fraud / Rank Manipulation

The target is "exposure slots": trending lists, recommendation feeds, search rankings. The tradecraft is fake plays, likes, comments, and keyword stuffing. Unlike type 2 it produces no transactions — it pollutes your content ecosystem. The deadliest effect is Gresham's law for content: when real creators see that brushing beats creating, the platform is finished.

Type 4: Quota Theft

The new species of the vibe era. If your product wraps metered resources — LLM APIs, SMS gateways, cloud storage — attackers will steal your keys or quotas and resell them. Tradecraft includes scraping hardcoded keys from your frontend, farming free-tier accounts for resale, and abusing your "free trial" endpoints as relay proxies. Signatures: non-human call patterns (steady high frequency, no day-night rhythm) and abnormal token-consumption shapes (超长 inputs, batch jobs).

With the four profiles drawn, the defense logic is clear: there is no silver bullet, only defense in depth. Betting everything on one layer is like betting one door against every thief.

The Four-Layer Defense System: Defense in Depth from Registration to Business

The core architecture fits on one diagram — print it and tape it next to your monitor:

Figure 1: The four-layer defense system. Each layer does one job: intercept early, divert early — never bet all your fraud prevention on a single layer.

The design philosophy is rising cost, rising precision: earlier layers are cheap (a few milliseconds per check) and cheap to get wrong; later layers are expensive (human review) but far more accurate. Requests flow left to right like water — whatever can be stopped early must never reach the expensive layers.

Layer 1: Registration — Set the Bar Where Bonus Abuse Stops Paying

The goal of the registration layer is not "zero fraud" but raising the cost of fraud. Attackers run businesses: when acquiring one account costs more than the bonus it yields, they move on to the next target.

• Email verification + disposable-domain blocklist: block the thousands of known throwaway email domains (public lists exist). This is the cheapest cut you can make and it kills over 30% of scripted registrations.
• Phone verification: burner-number services mean SMS verification is no longer a fortress, but it remains a cost lever — a few cents per number times ten thousand numbers is real money. Pair it with "one number verifies at most N accounts per 24 hours" for double effect.
• Invite-code gating: the most effective move during beta. Invite codes turn "indiscriminate attack" into "targeted breach," shrinking the attack surface by two orders of magnitude. Open up gradually once you have a user base and fraud data.
• Registration cadence limiting: more than N registrations per hour from one IP/device goes straight to manual review. Limit the cadence, not the total — real users don't register five accounts in one minute.

A litmus test: if your signup flow takes a human 30 seconds, a script does it in 3 — your barrier is paper. Vibe coders love to skimp here ("ship first, harden later"), and what ships first is the attacker's script.

Layer 2: Device — Identify Devices, Not People

Accounts are infinite; devices and IPs are scarce. The device layer's job is clustering "accounts" into "gangs."

• Device fingerprinting: collect dozens of dimensions (Canvas, WebGL, font lists, screen resolution, timezone) into a stable ID. Mind the compliance boundary: fraud-prevention use only, no cross-site tracking, and say so in your privacy policy. Open-source options (e.g., the open-source FingerprintJS) are plenty for indie projects — don't buy enterprise services on day one.
• IP reputation: datacenter IPs, proxy IPs, and Tor exit nodes are publicly listed. Dozens of "new users" from one IP block in a short window gets flagged. Cloud provider IP ranges update regularly — make this check a cron job.
• Association graph (lite): no graph database needed — one relational table suffices: record "account–device–IP–payment method" links. When 50 accounts share 3 devices, the gang reveals itself. A vibe project can run this on one Postgres table plus a scheduled SQL query.

-- Lite gang discovery: find account clusters sharing devices
SELECT device_fingerprint, COUNT(DISTINCT user_id) AS account_cnt,
       COUNT(*) AS event_cnt
FROM risk_events
WHERE created_at > NOW() - INTERVAL '24 hours'
GROUP BY device_fingerprint
HAVING COUNT(DISTINCT user_id) >= 5
ORDER BY account_cnt DESC;

Run this SQL once a day and you'll catch 80% of mass-registration gangs. Don't underestimate the "rustic" approach — the first principle of fraud prevention is data, not models. Get the data loop running before talking about machine learning.

Layer 3: Behavior — Watch the "How," Not Just the "Who"

The device layer answers "who the gang is"; the behavior layer answers "what they're doing." A real user has a human-smelling behavior sequence: browse, hesitate, compare, order — with human-paced intervals. A script smells mechanical: register → claim → order → cash out, four steps in 40 seconds, near-zero interval variance.

• Progressive per-action rate limiting: note the word "progressive." Login rate limiting is per-IP per-minute; business rate limiting must be per "action × account × window": e.g., "one account claims at most 2 coupons per hour," "one device places at most 5 orders per 24 hours." Derive thresholds from your real users' P99, not from thin air.
• Behavior-sequence anomaly: record the critical path (register → verify → claim → order → pay) as an event stream and compute two metrics: path completion speed and step-interval variance. Scripts are "too fast, too uniform" — median human time from registration to first order might be 2 hours; a script does it in 47 seconds.
• Escalating human verification: when behavior looks suspicious but evidence is thin, don't ban — throw a human-verification challenge (Turnstile/reCAPTCHA). This is the core move of the "throttle" tier: one extra click for real humans, a brick wall for scripts.

Layer 4: Business — A Rules Engine Guarding the Money

The first three layers are generic; this one is yours alone — and it has the highest ROI. Because only you know how your money gets taken.

• New-user high-value coupon circuit breaker: example rule — "accounts younger than 24 hours redeeming coupons ≥ $7 go to the manual review queue automatically." The essence of a circuit breaker is "block first, review later": before money leaves, everything is still fixable.
• Suspicious-order review queue: triggers include first order being large, shipping address changing frequently, and payment-method country mismatching registration country. The queue needs an SLA (e.g., cleared within 4 hours) or real users' experience dies in the wait.
• Rules engine: keep rules as configuration, not hardcoded branches. The simplest workable implementation for a vibe project: a rules table in the database (condition expression + action + priority) toggleable from an admin panel. Don't adopt a heavyweight engine like Drools on day one — until you have 50+ rules, you don't deserve a rules-engine framework.

One sentence to carry through all four layers: the objective function of fraud prevention is not "catch every bad actor" but "make fraud unprofitable without hurting good users." Any fraud control that blocks legitimate users is a failed control.

Putting It in Production: Risk Scoring, Graduated Response, Appeals

Four layers are the skeleton; risk scoring plus tiered response is what makes it move. The flow:

Figure 2: The risk-scoring pipeline. Score → three-tier response → appeal loop. Validate thresholds in canary before full rollout.

A Weighted Scoring Table You Can Copy

Don't let "machine learning" intimidate you. For 90% of vibe-project scenarios a weighted scoring table is enough — each risk signal gets a weight, summed into a 0–100 score. Set initial weights by gut feel, then tune after two weeks of data. Example:

// Pseudocode: risk score = sum of signal weights, capped at 100
score = 0
score += 25 if email_domain in DISPOSABLE_DOMAINS      // throwaway email
score += 20 if ip_reputation in (DATACENTER, PROXY)    // datacenter/proxy IP
score += 15 if device_accounts_24h >= 5                // many accounts, one device
score += 15 if reg_to_order_minutes < 10              // suspiciously fast first order
score += 10 if coupon_value >= 7 and account_age_h < 24   // new account, big coupon
score += 10 if behavior_variance < 0.1               // eerily uniform intervals
score += 5  if order_time in (0, 5)                    // 3 AM order (weak signal)
score = min(score, 100)

Three design notes. First, weak signals are harmless alone and lethal in combination — plenty of normal users order at 3 AM, but "3 AM + new account + big coupon + datacenter IP" together is almost certainly a farm. Second, weight changes need a changelog: who changed what and why, for post-mortems. Third, decouple scoring from response: scoring outputs only a number; response logic reads only the band. That way tuning thresholds never requires code changes.

Three-Tier Response: Observe / Throttle / Ban

• Observe tier (0–30): let through normally, but tag. Tags pay off in post-mortems — when a batch of accounts is later confirmed fraudulent, their score distribution tells you exactly where to move thresholds.
• Throttle tier (30–70): degrade core actions + human-verification challenges. E.g., coupon claims require verification, withdrawals settle after a 24-hour delay. The philosophy: make suspicious users feel friction, not targeted — one extra click for a human, a dead end for a script.
• Ban tier (70–100): block or ban, with money-touching actions routed to manual review. Note: a ban is always "account + device + IP" combined — banning only the account bans nothing, since registering a new one costs the attacker 3 seconds.

The iron rule of threshold rollout: canary first, full rollout later. New thresholds go live on 5% of traffic for 48 hours. Watch two metrics: catch volume (are we catching real bad actors?) and appeal volume (are we hurting real users?). If appeals spike, roll the threshold back immediately. Too many teams ship a gut-feel threshold to 100% on day one and spend day two drowning in support tickets from legitimate users.

The Appeal Channel: Fraud Prevention's Airbag

Even the best system false-positives. A fraud system without an appeal channel is incomplete — wrongly flagged users with nowhere to turn simply churn, and you'll never know why.

• Blocked/throttled pages must show a clear appeal entry point, not a dead-end "system busy" message. State what happened (vaguely, e.g., "unusual activity detected"), how long until resolution, and where to appeal.
• Appeals go through human review with a 24-hour SLA. Review outcomes feed back into scoring: confirmed false positives become training data for lowering the offending signal's weight — every false positive is tuning data.
• Plug into your existing human-approval workflow: if your project already has one (order review, content review), reuse it for the appeal queue instead of building a second system.

The Data Loop: Making Fraud Prevention Smarter Over Time

Launch day is not the finish line — it's the starting line. Attackers evolve, so your rules must evolve. Data is the fuel.

Fraud-Event Instrumentation: Data Before Intelligence

Four mandatory events: risk.scored (every score: value plus signal breakdown), risk.action (every response: tier plus action taken), risk.appeal (every appeal: reason plus outcome), risk.confirmed_fraud (post-hoc confirmed fraud: via human review or user report). Snapshot the feature vector with each event — without snapshots, the post-mortem question "why did this only score 40?" is unanswerable.

The 15-Minute Weekly Fraud Patrol

Indie developers can't watch dashboards all day. Spend 15 fixed minutes weekly on five numbers:

• Week-over-week tier volumes: throttle tier suddenly doubled? Threshold drift or a new attack wave.
• Appeal rate = appeals / actions: above 5% means too many false positives — tune thresholds before adding rules.
• Miss rate on confirmed fraud: of accounts later confirmed fraudulent, how many scored only "observe"? Direct input for weight tuning.
• Top-3 signal hit distribution: a signal suddenly hitting zero may mean attackers changed tradecraft.
• 7-day retention of new users, flagged vs. unflagged: if flagged accounts retain better, your controls are chasing away good users.

Attack-Defense Post-Mortem Template

After every major incident (losses exceeding a week's revenue, or 100+ accounts affected), run a 30-minute review answering four questions: What exactly did the attacker do (step by step)? Which layer should have stopped it but didn't? What one rule or weight change would have stopped it? How large is that rule's false-positive blast radius? The write-ups accumulate into your "attacker tradecraft knowledge base" — a vibe project's most valuable fraud asset isn't code, it's that knowledge base.

Scope Declaration: What This Guide Does Not Cover

Drawing boundaries so you reach for the right medicine: for login-layer brute-force protection (SMS code rate limiting, credential stuffing defense), see the SMS OTP login guide; for web attack protection (SQL injection, XSS, CSRF), see the web security baseline guide; for supply-chain security (dependency poisoning, lockfile verification), see the dependency supply-chain guide. This guide covers business-layer fraud only — four guides, cross-linked, each minding its own lane.

One-line summary: fraud prevention is not a one-time pre-launch project; it's ongoing operations after launch. Four layers give you the skeleton, weighted scoring gives you the brain, and the data loop gives you evolution. Don't wait until you're fleeced bald to think about fraud prevention — by then the tuition costs ten times more.