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 Subscribe to Newsletter 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 tri...