Fraud

Offensive Fraud Prevention

Patrick Mathieu

08 Apr 2026 — 5 min read

To follow the previous article "Fraud & Application Security: Ignoring each other is costing your business!",

Business logic flaws, not SQL injection, are where the real money disappears!

Traditional penetration testing, SAST and scanners catch technical vulnerabilities, while fraud-enabling business logic defects drain $12.5 billion annually from U.S. consumers alone!

This gap exists because security teams report to the CISO/CSO and track CVEs, while fraud teams report to the CFO or VP of Engineering and track chargebacks. Neither side systematically tests whether an application's business workflows can be weaponized.

This is the core argument behind "Offensive Fraud Prevention," a concept I championed at the end of 2025. The approach is straightforward: apply pentesting methodology to fraud scenarios, test what automated scanners structurally cannot detect, and produce findings measured in dollars lost rather than CVSS scores. Real metrics that the business can understand.

Business logic attacks now represent 27% of all API attacks (a 59% year-over-year increase between 2023 and 2024). An example would be coupon and discount abuse cases where the validation, rate limiting, or even race conditions which can be exploited. A great example is HackerOne report on Stripe: researcher Ian used Burp Suite's Turbo Intruder to exploit a race condition, applying a $20,000 fee discount 30 times in parallel, producing $600,000 in fee-free transactions. Stripe's initial fix was also bypassed. But we can also think of basic abuse cases like predictable code formats (PREFIX + sequential number or a year) that are routinely brute-forced.

The other incentive for criminals is loyalty program fraud, which targets an enormous pool of stored value: $48 billion in unredeemed points and miles in the U.S. alone! Or even refund abuse, which now constitutes a $103 billion problem. Gift cards are also an issue with $217 million in losses in 2023!

And the list goes on and on, from GPS spoofing to bypass geoblocks on applications to using VPNs or proxies to change IPs.

Lack of rate limiting and throttling

Every fraud category above becomes exponentially more dangerous when rate limiting fails, and sadly rate limiting fails constantly. The techniques are well-documented and trivial. For example, header spoofing: the Mastodon CVE (GHSA-c2r5-cfqr-c553) revealed that setting X-Forwarded-For: 127.0.0.1 bypassed all rate limiting because localhost was explicitly exempted.

Lack of rate limiting and throttling can lead to data exfiltration. If you have a security issues that offer exfiltration or a support agent that start exiltrating all customer base data, these security measures are helpful, if well implemented.

And we can't relay on security measure based on IP anymore. IP rotation is now easy with residential proxies, AWS API Gateway, and many other cloud and proxy services offering you free or cheap IPs. Limiting by IP is a thing of the past. Not that you should not do it, but it should not be your only line of defence. And so many more bypasses exist!

Data exfiltration through legitimate features

One of the most interesting and most impactful issue is using legitimate application features and functions to abuse the system and extract data.

Automated (or chained) IDOR (Insecure Direct Object Reference) is widely used for exfiltration:

The Dell API breach of 2024 exposed 49 million customer records through a misconfigured partner portal API
Spoutible's API allowed incrementing user IDs to harvest bcrypt password hashes
Uber breach allowed 600 000 users data exfiltration through the use of IDOR.
... and many more.

Why security and fraud teams don't talk to each other

The structural separation runs deep. Security teams deploy vulnerability scanners, SIEMs, and EDR tools. Fraud teams deploy transaction monitoring, behavioral analytics, and chargeback management platforms. Security teams measure time-to-remediation, SLAs, and vulnerability counts. Fraud teams measure loss rates and false positive ratios. Business logic flaws that enable fraud sit precisely in the gap between these two domains.

Fraud is too "business" for security teams, and it's too "technical" for fraud teams to analyze badly designed applications and their features.

I've seen login teams not taking into consideration metrics about bots, fraud, and attacks while measuring their login conversion rates... while none of their data had any value whatsoever. And I've seen fraud teams ignoring the root cause of the fraud and only deploying basic mitigation to reduce money loss instead of remediating the core issue with the application security team.

Subscribe to Security Autopsy

But no fraud testing framework exists yet. Here's what to use instead

First, we can't use CVSS. Business logic issues won't score high enough, so we need to build a new approach. This approach needs to test the following:

Price/payment integrity - can the application be tricked into processing transactions at the wrong price?

Modify price fields or submit negative quantities to generate credits instead of charges
Swap currency codes (USD to INR) while keeping the numeric value
Navigate directly to order confirmation URLs without completing payment
Replay successful payment tokens on new, different orders
Tamper with payment gateway callback signatures and amount fields

Workflow circumvention - does the application enforce step sequence on the server side?

Skip checkout steps by accessing later stages directly via URL or API
Replay single-use artifacts (coupons, gift cards, promo codes) across separate transactions
Earn loyalty points on a purchase, cancel it, and check if points persist
Modify order status fields (pending to completed) in API requests
Resume abandoned flows from a later step using captured request data

Rate and limit abuse - We covered why rate limiting fails above. Here is how to test it specifically:

Spoof origin headers (X-Forwarded-For: 127.0.0.1) to bypass IP-based limits on financial endpoints
Use GraphQL alias batching to pack multiple mutations into a single POST the rate limiter counts as one
Test race conditions on every single-use operation (coupon apply, point redemption, refund) with 20+ parallel requests
Brute-force predictable gift card or coupon code formats
Rotate IPs via FireProx or residential proxies to defeat per-IP throttling

Authorization boundaries - does every financial action check who is asking?

Replay every financial action as every role using AuthMatrix
Attempt IDOR on orders, invoices, point balances, and refund records by changing the object ID
Test segregation of duties: can the same person initiate and approve a refund
Modify role claims in JWTs or session cookies and check if the server trusts them
Check whether support agents can issue refunds to their own accounts

Refund and loyalty exploitation - can value be extracted that was never legitimately earned?

Submit the same refund request multiple times rapidly to trigger double refunds (race condition)
Modify refund amounts to exceed the original purchase or redirect to attacker-controlled accounts
Loop the earn-then-cancel cycle to accumulate free loyalty points indefinitely
Race-condition gift card redemption from parallel sessions to drain a card multiple times
Purchase a gift card, use it, refund the original purchase, and check if the card balance is clawed back

What's next?

OWASP launched a Business Logic Abuse Top 10 in May 2025, which signals the industry is waking up. But, let's push it further.

Now that we understand that fraud is sometimes more important than application vulnerabilities, that we know what to test for, and how to reduce fraud at its core by identifying badly designed applications and legitimate features, we can move forward and help our organizations reduce their money loss.

But there's a better approach that can help everyone is not just building a Top 10, but :