In November 2023, OWASP added a new entry to its API Security Top 10 that had nothing to do with broken authentication, injection, or misconfigured headers: API10:2023, "Unrestricted Access to Sensitive Business Flows." It described something security teams had been quietly losing sleep over for years — attackers who never break a single security control, never trigger a WAF signature, and never touch a vulnerable endpoint, yet still cause real financial damage. They just use the API exactly as designed, over and over, faster than any human could. Think bots buying out an entire concert's ticket inventory in 90 seconds, or scripts creating thousands of fraudulent accounts to claim a $20 sign-up bonus. No CVE gets filed. No patch gets released. The business flow itself is the attack surface, and most companies have no idea it's exposed until the finance team asks why margins collapsed.
What Is "Unrestricted Access to Sensitive Business Flows"?
It's an API security gap where a legitimate, correctly-implemented business process can be automated and abused at a scale the business never anticipated. OWASP's official definition describes flows that "could cause harm if used excessively" — things like purchasing limited-inventory items, posting reviews, redeeming coupons, or creating accounts. The API itself has no bug. Authentication works, authorization works, input validation works. The problem is that nothing distinguishes a real customer clicking "buy" once from a bot clicking "buy" 50,000 times in the same second. Because this isn't a coding defect, it's invisible to SAST, DAST, and dependency scanners — the exact tools most AppSec programs rely on. That gap is why OWASP carved out a dedicated category instead of folding it into rate limiting (API4) or broken function-level authorization (API5).
Why Did OWASP Add This to the 2023 Top 10 Instead of Earlier?
Because the 2019 API Security Top 10 didn't have a category that fit, and the losses had become too large to ignore. Between the 2019 and 2023 OWASP API Security Top 10 releases, e-commerce, ticketing, and fintech APIs went from a handful of REST endpoints to sprawling public surfaces consumed by mobile apps, partners, and increasingly by bots built with off-the-shelf automation frameworks. Imperva's 2023 Bad Bot Report found that automated traffic accounted for 47.4% of all internet traffic in 2022, and "bad bots" — the kind used to abuse business logic — made up 30.2% of it, the highest share Imperva had recorded in the report's history. Ticketing is the poster child: resale platforms and StubHub-adjacent research have repeatedly pointed to bots acquiring a large share of high-demand concert inventory within minutes of on-sale, well before human fans can complete checkout. OWASP's working group concluded the industry needed a named category so architects would design for it up front, rather than bolting on defenses after a launch goes viral for the wrong reasons.
What Does This Kind of Attack Actually Look Like in Production?
It looks like completely normal API calls, just an abnormal number of them from an abnormal number of identities. A gift-card balance-checking API, for example, accepts a card number and PIN and returns a balance — a legitimate, needed function. Attackers script it to test thousands of guessed card/PIN combinations per hour, a pattern security researchers have documented repeatedly against retail gift card programs, sometimes draining balances before the real cardholder ever redeems them. Sneaker and PS5-style "restock" bots do the same thing to checkout and cart-reservation APIs: they hold inventory in carts without ever completing payment, so real customers see "sold out" while resale listings for the same item appear on secondary markets within the hour. Airlines and hotel booking APIs face "scraping-to-scalp" flows where competitors or resellers hit fare-search endpoints millions of times a day — Akamai has publicly described travel-sector clients seeing scraping traffic exceed genuine customer search traffic by wide margins during peak booking windows. In each case, a security scanner sees 200 OK responses and moves on.
Why Doesn't Basic Rate Limiting Solve This?
Because rate limiting caps requests per key or IP, and sophisticated abuse is specifically engineered to stay under that cap while distributing across thousands of identities. An attacker running a credential-stuffing-adjacent gift card attack doesn't send 10,000 requests from one IP — they rotate through residential proxy pools, sometimes tens of thousands of IPs sourced from compromised consumer devices, so each source makes only a handful of requests. A rate limit set at 100 requests per minute per IP is trivially satisfied by 500 IPs each sending 20. The same evasion applies to device fingerprints, account creation, and session tokens: attackers rotate whatever variable the defense keys on. Rate limiting also can't distinguish intent — it can't tell that account number 4471 checking a gift card balance is the 900th distinct-but-related check in the last hour across a botnet, because from that single API's point of view, it's one request from one client. Effective defense requires correlating behavior across sessions, time, and identity — which means understanding the business flow, not just counting requests against it.
Which Industries Carry the Most Exposure?
Any business with a limited or time-sensitive resource behind a public API — retail, ticketing, travel, and fintech lead by a wide margin. Retail and e-commerce APIs face inventory-hoarding and gift-card/loyalty-fraud flows; the 2023 Imperva report ranked retail among the top three industries by bad-bot traffic share for the fourth consecutive year. Ticketing and live events face on-sale-minute scalping that regularly makes headlines — the U.S. Federal Trade Commission and multiple state attorneys general have pursued ticket-bot cases under the BOTS Act since 2016, yet the underlying API abuse pattern hasn't gone away because the fix has to happen at the API layer, not just through legislation. Fintech and neobank APIs face fraudulent account-opening flows designed to farm sign-up bonuses or launder stolen card data through micro-transactions. Even B2B SaaS platforms aren't exempt: free-trial and referral-credit APIs get farmed by scripts creating disposable accounts at a rate no legitimate onboarding funnel would produce. What unites all of them is a business process with real monetary value sitting behind an API that was built to be usable, not to be suspicious of its own users.
How Can Teams Tell If a Business Flow Is Already Being Abused?
Usually not from security logs — the first signal is almost always a business metric that stops making sense. A conversion rate that drops even as traffic climbs, an inventory system reporting "sold out" for items with no matching shipment volume, or a coupon-redemption rate that's 40x the historical baseline are the kinds of anomalies that tip teams off, often weeks after the abuse started. By the time finance or product teams notice, the API logs already contain the evidence — it's just never been correlated against the business logic to flag it. This is the core diagnostic challenge of API10:2023: the request logs look clean because, technically, they are clean. Detecting the abuse requires mapping which endpoints represent sensitive business flows in the first place, something most organizations have never formally inventoried.
How Safeguard Helps
Safeguard approaches unrestricted business-flow access as an inventory and context problem before it's a blocking problem, because you can't defend a flow you haven't identified as sensitive. Safeguard's API discovery continuously maps every endpoint in your environment — including shadow and undocumented APIs — and flags those tied to high-value business logic: checkout, account creation, coupon redemption, balance lookups, and similar flows that OWASP's API10:2023 calls out by name. That inventory is cross-referenced against real traffic patterns to surface behavioral anomalies that per-endpoint rate limits miss entirely, such as low-and-slow requests distributed across thousands of rotating identities hitting the same sensitive flow.
Because Safeguard is built for software supply chain and API security together, it also traces which services, third-party integrations, and CI/CD-deployed code paths expose these flows externally, so a newly shipped checkout microservice or partner-facing loyalty API gets classified and monitored from day one rather than discovered after an incident. Rather than asking teams to hand-write bot rules for every business process, Safeguard gives security and product teams a shared, continuously updated map of which APIs matter most to the business, and the anomaly context needed to act before a bot economy forms around them — closing the exact gap OWASP defined in API10:2023, at the point where scanners and rate limiters stop being useful.