OWASP API #6: Business Logic Flaws Explained

OWASP API #6: Unrestricted Access to Sensitive Business Flows

When your API works perfectly but still gets hacked (because attackers are clever)

Imagine you own a ticket selling website. You sell concert tickets. Your system works perfectly. People log in. They buy tickets. Everyone is happy.

Now imagine an attacker finds a way to buy 10,000 tickets in one second. They use a bot. They buy all the tickets before real fans can get any. Then they sell those tickets for triple the price.

Your system worked exactly as designed. Nothing was broken. No vulnerability in the code. No SQL injection. No authentication bypass.

But you still lost millions of dollars.

That is what OWASP API #6 is about. Not broken code. Broken logic. The things you never thought about when you designed your business flow.

What Is Unrestricted Access to Sensitive Business Flows?

Let me break down that long name.

Business flow means the steps a user takes to accomplish something.

Log in. Add to cart. Checkout. Pay. Reset password. Transfer money.

Sensitive business flows are the ones that matter. Buying tickets. Transferring money. Resetting passwords. Accessing sensitive data.

Unrestricted access means there are no limits. No rate limits. No checks. No verification. Anyone can do anything as many times as they want.

Put it together. Unrestricted Access to Sensitive Business Flows means your API allows attackers to abuse important business functions as much as they want.

This is not about breaking your API. This is about using your API exactly as it was designed. But using it in ways you never intended.

A Story About Instagram and Mr X

Let me tell you a real story about Instagram.

Imagine you want to take over Mr X's Instagram account. Not because you should. But because this is a story about security.

You go to Instagram. You click "Forgot password." You enter Mr X's username. Instagram sends a 6-digit reset code to Mr X's phone. You do not have her phone. You cannot see the code.

But here is the thing. Instagram has an API where you can submit your guess for that reset code.

A 6-digit code has 1 million possible combinations. 000000 to 999999.

So you start guessing. 000000. 000001. 000002.

Instagram has protections. You only get 200 guesses. After 200 wrong guesses, you are blocked.

You think you are done. It will not work.

But then you try something. You change your IP address. You get 200 new guesses. You change your IP address again. Another 200 guesses.

There are millions of IP addresses. You can keep changing forever.

You automate this. You distribute it across many computers. Within minutes, you try all 1 million combinations. One of them is correct. You reset Taylor Swift's password. You take over her account.

Instagram's password reset flow worked exactly as designed. Nothing was broken. But the logic was flawed. IP address should not have mattered. 200 guesses was too many. The reset code should have expired after a few wrong guesses.

That is unrestricted access to a sensitive business flow.

The Happy Path vs The Evil Path

When developers build applications, they think about the happy path.

Happy path: User forgets password. User requests reset. User receives code. User enters code. User creates new password. User logs in. Everyone is happy.

Developers test the happy path. It works. They ship the code.

But attackers do not take the happy path. They take the evil path.

Evil path: Attacker pretends to be Taylor Swift. Attacker requests reset. Attacker cannot see the code. Attacker guesses the code 1 million times. Attacker changes password. Attacker takes over account.

Developers did not test the evil path. They did not think about it. That is why this vulnerability exists.

The lesson is simple. You must test both paths. The way your application is meant to be used. And the way it could be abused.

Real Examples of Business Flow Abuse

Here are some real examples of how attackers abuse business flows.

Concert tickets. An attacker uses bots to buy thousands of tickets in milliseconds. Real fans get nothing. Attacker sells tickets for triple the price.

Coupon codes. An attacker finds an API that applies discount codes. There is no limit on how many times a code can be used. The attacker uses the same 50% off coupon 10,000 times.

Referral programs. An attacker creates 10,000 fake accounts. Each account refers the next account. The attacker collects referral bonuses for all of them.

Password reset. The Instagram story you just read. Attacker brute forces reset codes by changing IP addresses.

Incremental IDs. An attacker sees that order IDs are sequential. Order ID

1, 2, 3, 4

1, 2, 3, 4

They guess Order ID 100000 and see someone else's order. They keep guessing and download millions of orders.

Voting systems. An attacker finds a voting API with no rate limiting. They vote 1 million times for their favorite candidate.

Inventory checking. An attacker builds a bot that checks inventory for a rare item every millisecond. When the item comes in stock, the bot buys it instantly. Real users never get a chance.

These are not vulnerabilities in the code. The code works fine.

These are vulnerabilities in the logic. The developers did not think about abuse.

How to Protect Against Business Flow Abuse

Here are the things you need to do.

First, rate limit everything. How many times can a user request a password reset? How many guesses do they get? How many times can they apply a coupon code? How many votes can they cast? Put limits on everything.

Second, expire things quickly. A password reset code should expire after 5 wrong guesses. Not 200. Not 200 plus changing IP addresses. Five wrong guesses and the code is dead. Request a new one.

Third, do not trust client-side information. IP address should not determine how many guesses someone gets. Attackers can change IP addresses easily. Use something the attacker cannot change. Like the user session or the reset code itself.

Fourth, use unpredictable identifiers. Do not use sequential IDs.

Do not use 000001, 000002, 000003.

Do not use 000001, 000002, 000003.

Use random strings. Use UUIDs. Make it impossible for attackers to guess the next one.

Fifth, monitor for abnormal patterns. If one user is making 10,000 requests per minute, that is not normal. Block them. Alert your security team. Investigate.

Sixth, test for abuse. Hire ethical hackers to try to break your business logic. Not just your code. Your logic. Your flows. Your assumptions.

The Difference Between Code Vulnerabilities and Logic Vulnerabilities

This is important to understand.

A code vulnerability is a bug. SQL injection. Cross-site scripting. Buffer overflow. These are mistakes in the code. They can be found with scanners.

A logic vulnerability is not a bug. The code works exactly as written. The problem is in the design. The problem is in the assumptions. The problem is in the things the developer did not think about.

Scanners cannot find logic vulnerabilities. You need human testers.

You need to think like an attacker. You need to ask "What would happen if someone did this 10,000 times?"

Many companies have great security testing for code vulnerabilities. Almost no companies have good testing for logic vulnerabilities.

That is why OWASP added this to the Top 10. Because it is a huge gap.

One Final Thought

Every developer tests the happy path. Does the user get their password reset code? Yes. Does the user enter the code and reset their password? Yes. Ship it.

But attackers do not take the happy path. They take the evil path.

The evil path is longer. It has more twists. It is where the flaws hide.

Your job is to walk the evil path before the attackers do. Think like them. Try to break your own business logic. Fix what you find.

Because the attackers are already walking that path. Do not let them be the first ones to find your flaws.