Business Logic & Service Abuse Validation
Whether your business rules hold outside the normal procedure
We test whether your business rules can be abused outside the normal procedure in ways that cost you money or expose data.
We look at business rules such as coupons, points, refunds and bookings, the core logic inside your apps and clients, and the boundaries of a service that many client companies share. First we set the conditions that must hold, such as ‘once a payment is complete, its amount cannot change’; then we follow the scenarios that could break them and see whether they really get through.
Do our business rules still hold when someone steps outside the normal procedure?
We follow the scenarios that would break the conditions you rely on, confirm whether they can really be abused, and show the business impact and where to stop it first.
Reviewed
When it fits
- Money and rewards change hands in your service
Commerce, bookings and ticketing, finance and points, games, subscriptions: services where use outside the normal procedure turns straight into lost money or unearned benefits.
- A promotion or payment policy is new or changing
You are launching or changing coupons, referral rewards, refund rules or pricing plans, and want to know whether the conditions you set leave room for abuse.
- Critical logic ships inside an app or device
Your mobile app or IoT device carries payment, authentication or licence logic along with keys and settings, and you want to know whether analysing or modifying the app or device gets around that logic.
- Many client companies share one service
On a B2B SaaS product or platform, you want to know that one client company's data and functions are not open to other client companies, or to admin and support functions, beyond what is needed.
What we look at
Three areas: business rules and flows, the logic inside apps and clients, and roles and the boundaries between client companies. We pick and combine them to fit the target and your worry.
- RULESBusiness rules and flows
- Price, quantity and discount calculations
- Payment, cancellation and refund flows
- Coupons, points and rewards used more than once
- Skipped processing steps and approvals
- Protection against bulk automated requests such as macros and bots
- CLIENTLogic inside apps and clients
- How hard the app or client code is to analyse
- Integrity checks and tamper detection
- Keys, settings and critical logic shipped inside the app
- How well payment, authentication and licence logic are protected
- TENANTRoles and client boundaries
- Using features meant for another user's role
- Separation of data, files and search between client companies
- How far admin and support functions reach
‘Once a payment is complete, its amount cannot change’
‘A modified app cannot use payment or sign-in features’
‘One client company's data is never visible to another’
How it runs
Set the protection goal
We pick the loss you are worried about, then set the conditions that must hold to prevent it and the functions and business flows involved.
Agree scenarios and safety
We choose the scenarios that could break the conditions, and agree the accounts and environment needed, what is permitted and when to stop, before we start.
Validate the scenarios
We follow each scenario and see whether the condition holds, breaks, or has nothing in place to protect it.
Explain the results
For each scenario: the result and the evidence, the business impact, where to stop it first and how to improve.
Where money moves, as with payments and points, we agree the test environment and method with you so that real customers and transactions are not affected.
What you receive
Results by scenario
Each scenario is marked stopped, got through or needs work, with the conditions that make it so.
Business impact
What each result would cost in money, benefits or data: discounts paid twice, wrongful payouts, another client company's data exposed.
Evidence
The steps and proof needed to reproduce what we found.
Improvement and what was not covered
Where to stop it first, how to improve, and which parts this round did not examine.
A coupon or points can be used only once, under the set conditions
Target: a commerce app and its order and payment APIs
| Scenario | Result | Evidence |
|---|---|---|
| Normal order and payment | Stopped | The server recalculates the discounted amount itself. |
| Cancellation overlapping with reuse | Got through | The same coupon can be applied a second time. |
| The price the app sends | Stopped | The price sent by the app is ignored; payment uses the server value. |
| Referral points | Needs work | Points build up with every new account, with no limit and no check for bulk sign-ups. |
- Business impact
- Discounts paid out more than once, and promotion budgets spent on accounts created only for points.
- How to improve
- Handle coupon use and restoration as one step; add identity checks, payout limits and checks for bulk sign-ups to referral points.