Referral and Bonus Abuse: Business Logic Bugs That Pay

Referral and Bonus Abuse: Business Logic Bugs That Pay

No injection, no XSS, no clever payload — just a system that hands out money and a set of rules with holes in them. Referral and bonus abuse is pure business logic, and programs pay for it because it maps directly to dollars leaving the company. If $10 in credit appears for every signup, an attacker who mints a thousand signups just cost real money.

Read the rules like an accountant

Before testing, map the economic flow. Who gets credited, when, and what condition triggers it? Common triggers: a friend signs up, makes a first purchase, verifies a phone, or stays active seven days. Each condition is a check, and each check is a place the logic can be fooled.

Ask the annoying questions: Can the referrer and referee be the same person? Is the bonus granted on signup or on a validated action? Can it be reversed if the underlying action is undone?

Self-referral

The oldest trick, still alive. Sign up as the referrer, then sign up as your own referee and see if the bonus lands. Defenses to probe:

• Same email — blocked, so use plus-addressing (me+ref1@example.com) if the app normalizes inconsistently
• Same device or IP — blocked, so vary them
• Same payment instrument — the strongest check; if it's missing, self-referral scales freely

If you can complete the loop and credit yourself, quantify it: one account, one referral, $X. Then note it scales linearly with disposable emails.

Reversal and refund gaps

Here's a favorite. A bonus triggers on first purchase. Make the purchase, collect the bonus, then refund or cancel the purchase. Does the bonus claw back? Often not. You keep the credit, the money comes back, net gain. Same pattern with subscription trials that grant credit and then get cancelled before billing.

Races and stacking

Bonus systems love to double-apply under concurrency. Send the "apply promo code" or "claim referral" request several times in parallel (Burp's parallel send or a small script). If the check-then-credit isn't atomic, you may bank the bonus multiple times from one entitlement.

Stacking is the sibling bug: can you apply two promo codes that were meant to be mutually exclusive? Can a "first order" discount apply to your fifth order by manipulating the order count or a client-sent flag? Try sending isFirstOrder=true or a stale cart state and watch whether the server re-derives it or trusts you.

Prove it with numbers, not adjectives

This is where these reports win or lose. Triage for logic bugs wants a ledger, not a vibe. Show:

• Starting balance / entitlement
• The exact requests that triggered the improper credit
• Ending balance
• The per-iteration gain and how it scales

"I earned $30 in credit from three self-referrals in ten minutes using plus-addressed emails, and nothing prevents repeating it" is a report that gets paid. "Referral system looks abusable" is not.

Keep the demonstration small — prove the mechanism with two or three iterations, then describe the scale. Don't actually drain a promo budget or cash out; that crosses from research into fraud.

Fixes to recommend

Grant bonuses only on validated, non-reversible actions; claw back on refund or cancellation; enforce uniqueness on a strong identifier (payment method, verified phone) rather than just email; make claim operations idempotent and atomic to kill races; and re-derive economic flags like "first order" server-side instead of trusting the client.

OWASP's Business Logic Testing guide frames how to reason about abuse of intended functionality — the mindset that turns "weird promo behavior" into a quantified financial finding.