Imagine a customer stacks three discount codes and checks out for ₹1. Nothing was “hacked” — your app simply allowed it. That’s a business logic flaw, and it’s why we spend so much time understanding how your business works.
Why this matters to your business
Logic flaws hit revenue directly — free products, stacked discounts, unauthorized approvals. They are rarely found by tools, so they often survive until someone abuses them.
What is a business logic flaw?
Your app follows rules: who can approve a refund, when a discount applies, which step comes before payment. A business logic flaw is when those rules can be bent — the code works, but the outcome is not what the business intended.
Why tools miss them?
Scanners look for known technical patterns. They do not know that a coupon should only work once, or that a user should never approve their own expense. Spotting these needs someone who understands how your business works.
How to reduce the risk?
Write down the rules that matter most, enforce every rule on the server rather than in the browser or app, and include “what if someone does this out of order?” in your design reviews and tests.
Which businesses are most exposed?
Any business where software decides money, access or approvals: e-commerce and marketplaces, fintech and lending, booking platforms, loyalty programs, and internal tools that approve expenses or refunds.
How we test business logic?
We start by learning how your workflows are meant to work — often in a short call with a product owner. Then we test those rules from the point of view of each type of user, including what happens when steps are skipped, repeated or done out of order.
Real-world scenarios
Where business rules usually break
Discounts that stack
Several coupons combine into a near-free order.
Define which offers can combine and check it on the server.
Steps taken out of order
An order is confirmed without the payment step completing.
Confirm each step server-side before allowing the next.
Price taken from the browser
The amount charged comes from what the user’s device sends.
Always calculate prices on the server from your catalogue.
Approving your own request
A user approves their own refund, expense or limit increase.
Enforce separation of duties for every approval.
One-time offers used repeatedly
A referral or welcome bonus is claimed again and again.
Track and enforce single-use rules per account and device.
Quantity and limit bypass
Negative or extreme quantities change totals or stock.
Validate ranges and totals for every transaction.
Jargon buster
- Business logic
- The rules that decide how your app should behave, such as prices, limits and approvals.
- Workflow
- The order of steps a user follows, like cart → payment → confirmation.
- Server-side check
- A rule enforced on your servers, where users cannot change it.
How our team helps
- 01Learn how your workflows are meant to work
- 02Test rules across roles, steps and edge cases
- 03Explain each issue in business terms
- 04Retest after your fixes
- 05Map your key workflows with your product team
- 06Test rules from every user role’s point of view
- 07Explain the business impact in money and trust
From our work · technical details
How we handle this in Web Application VAPT
- Insecure direct object references (IDOR)
- Stored and reflected cross-site scripting
- Broken access control between user roles
- SQL injection in search and filter parameters
- Weak password reset flows
- Missing security headers and insecure cookies
Tell us how your workflows are meant to work — we’ll show you where they can be bent.
— The CRIS InfoTech security team