Business Logic Testing
Business logic testing that finds what scanners miss: price tampering, IDOR, workflow bypass and race conditions. Fixed price, free retest. Get a quote.
Business logic testing finds the flaws a scanner will never see: the checkout that lets you set your own price, the transfer that goes through with a negative amount, the workflow you can skip halfway. These bugs live in how your application is supposed to work, not in a missing patch, and only a human who understands the intended flow can break them on purpose.
What business logic testing actually covers
Most vulnerabilities in a modern web application are not classic injection bugs. They are decisions the code makes about what a user is allowed to do, and when. An automated tool sees a form that returns HTTP 200 and moves on. It has no idea that submitting the same order twice granted two refunds, or that a support agent could read another company’s tickets by changing one number. We test the rules your business runs on, the way an attacker who has read your pricing page and signed up for a trial would.
A business logic engagement maps every meaningful action a user can take, then asks what happens when that action is performed out of order, with the wrong values, at the wrong privilege level, or more times than intended. The scope is shaped around your workflows rather than a generic checklist.
Where logic flaws hide
They cluster around money and identity. Anywhere the application weighs one user against another, meters a resource, or trusts a value that came from the browser, there is a decision that can be pushed the wrong way. A field marked read-only in the interface is still editable in the request. A quantity validated in JavaScript is not validated on the server. A discount applied once was never designed to be applied twice in the same second.
Why business rules testing needs context
You cannot test a rule you do not understand. Before any request goes out, we sit with the intended behaviour: who is meant to do this, in what order, with what limits. Good business rules testing is half reading your product and half attacking it. That is also why it does not automate well, and why the findings tend to be the ones that keep a CFO awake rather than a line in a compliance spreadsheet.
How we run a business logic security testing engagement
Our approach follows OWASP testing guidance for business logic (the OTG-BUSLOGIC series) and OWASP ASVS, but the real work is manual. We use Burp Suite Professional to intercept and replay every request, and we drive the application by hand through each role. The phases below describe what an engineer actually does across a business logic security testing project.
Phase 1 — Understanding the application
We start by using the product as a real user across each role you provision for us. We document the workflows, the state each object moves through, the money paths, and the points where the server trusts the client. This map is what turns a generic test into an attack tailored to your logic.
Phase 2 — Threat modelling the workflows
For every workflow we ask three questions. What is the intended sequence? What would an attacker gain by breaking it? Which value, if changed, moves money or grants access? The answers become concrete test cases: replay this confirmation, tamper this total, call step four without doing steps one to three.
Phase 3 — Manual exploitation
This is where the flaws surface. We tamper prices and quantities, submit negative and boundary values, replay one-time tokens, fire parallel requests to trigger race conditions, and try to act as one tenant while authenticated as another. Every candidate finding is proven with a real request and response, then confirmed to be repeatable so there is no doubt it is genuine.
Concurrency and timing
Race conditions deserve their own mention. Sending twenty simultaneous requests to redeem a single coupon, withdraw a balance, or claim a limited item often produces more successes than the logic allowed for. We test these deliberately, because they rarely show up in single-threaded manual clicking and never in a passive scan.
Phase 4 — Reporting and retest
You get a written report while findings are still fresh, and a walkthrough call if you want one. After your team ships fixes, we retest every issue at no extra cost to confirm the logic now holds under the same attack.
Common business-logic flaws we find
The specific bugs differ by product, but they fall into a handful of recurring patterns. Here are the ones we prove again and again on real engagements.
Price and total tampering
The classic. The client submits the price or the order total, and the server stores it without recalculating from its own catalogue. We have bought products for a cent, applied a shipping credit larger than the order, and set a subscription tier to a lower plan’s cost while keeping the higher plan’s features.
Broken access control and IDOR
An identifier in a URL or request body points at a record. Change it, and you read or edit something that belongs to another user or another company. This is the most common serious finding in multi-tenant SaaS, and it maps directly to the top entry in the OWASP Top 10. We test every object reference across every role, not a sample.
Workflow and sequence bypass
Multi-step processes assume you go one, two, three. We call step three directly, or replay a “payment confirmed” callback the application trusts, and reach a state you were never meant to reach without paying, verifying identity, or getting approval.
Quantity, boundary and negative values
Refund a negative amount and you credit yourself. Order minus-one item and watch stock or a balance move the wrong way. Push a field past its intended maximum and see whether limits are actually enforced or just suggested in the interface.
Promotion, referral and rate abuse
Single-use codes reused, referral bonuses farmed with throwaway accounts, free-trial limits reset by manipulating an identifier. Where a feature costs you money per use, we test whether the meter can be spun.
Want this tested on your own systems?
Free 20-minute scoping call, a fixed price with no hourly surprises, and a free retest once you fix what we find.
What you get
The deliverable is written to be read by two audiences. Your leadership gets a short executive summary that says, in plain language, what an attacker could do and what it would cost the business. Your engineers get everything they need to reproduce and fix each issue.
- An executive summary framing business risk and the money or data at stake, not jargon.
- Each finding with a CVSS score, clear business impact, and step-by-step reproduction including the exact requests.
- A prioritized remediation plan your developers can action, with the specific control that closes the flaw.
- A free retest once fixes are deployed, plus an attestation letter suitable for customers, auditors or partners.
Because business logic findings are about how your product behaves, we write the reproduction steps so a developer who did not sit in the test can follow them and see the bug for themselves.
Compliance and standards
Business logic testing supports the application-security expectations in the frameworks European companies answer to. It is part of a credible OWASP ASVS assessment (particularly the access-control and business-logic verification requirements), it feeds the secure-development and testing controls in ISO 27001 Annex A.8, and it satisfies the application-layer penetration testing PCI DSS 4.0 requires under requirement 11.4 for anyone touching cardholder data.
SOC 2, GDPR and DORA
For SOC 2 the report evidences that you actively test the controls protecting customer data. For GDPR, a broken access-control flaw is a personal-data exposure waiting to happen, and testing for it demonstrates the “appropriate technical measures” the regulation asks for. Financial-sector clients under DORA can fold this into their threat-led testing obligations.
Why manual testing beats a scanner here
An automated scanner has no concept of intent. It cannot know that your platform should never let a buyer pay less than the listed price, because it does not know what the listed price means. It fires payloads at parameters and reports on error messages and known signatures. Business logic flaws produce no error. The application does exactly what the code told it to, which happens to be the wrong thing.
This is manual work by people who have found these bugs before. Our engineers hold OSCP and OSWE, and the value you are paying for is judgment: knowing which of a hundred requests is the one worth tampering, and recognising a successful abuse when the response looks completely normal.
Pricing
Cost depends on how many workflows and roles are in scope, how much money or sensitive data moves through them, and whether testing is authenticated across several user types. Here is the shape of a typical European engagement, and what drives business logic testing cost up or down.
| Engagement | What’s included | Timeline | Price |
|---|---|---|---|
| Essential | Single application, one or two roles, core money and access-control workflows, OWASP-aligned logic testing, full report, free retest | 3–5 working days | from €2,500 |
| Standard | Business app with several roles, an API and payment or subscription flows, race-condition and multi-tenant isolation testing, exec + technical report | 5–8 working days | €3,500–€8,000 |
| Advanced | Complex or high-value platform, deep authorization model, financial transactions, attack-chaining across workflows and integrations | 8–12 working days | €8,000–€20,000 |
| Compliance add-on | Mapping and attestation letter for PCI DSS, ISO 27001, SOC 2, GDPR or DORA | with any tier | from €800 |
| Custom / large estate | Multiple applications or a full product suite, scoped to your workflows | on scoping | custom |
Every engagement is fixed-price, quoted after a free 20-minute scoping call, so there are no hourly surprises and a retest is always included. Get a fixed quote
FAQ
How much does business logic testing cost?
How long does a business logic penetration testing engagement take?
How is this different from a normal web application pentest?
Do you test in production or a staging environment?
What do I get at the end?
Will this help with PCI DSS or ISO 27001?
Can you find race conditions and double-spend issues?
Are the findings kept confidential?
Related services
SaaS platforms, e-commerce and fintech products, and any application where users move money, share a tenant boundary, or run through multi-step workflows that assume good behaviour. If a clever customer changing a value in their browser could cost you revenue or expose another account, this is the test that finds it first.
Security you can prove
The same standard on every engagement, big or small.
Evidence, not opinions
Every finding ships with a reproduction and proof of concept — no vague "maybe vulnerable".
Humans over scanners
Certified engineers find the logic flaws and chained attacks automated tools walk straight past.
Fixed price, free retest
You know the cost up front, and verifying the fix is part of the deal — not a second invoice.
Ready to lock this down?
Free scoping call, fixed price, free retest. Tell us what you're running and we'll take it from there — usually within one business day.
Tell us what you're running
Scoping is free. We reply within one business day, and under 30 minutes for active incidents.