Home / Attacks & tests / Business Logic Testing
8 test cases
Business Logic Testing
Business logic testing examines whether the application's rules hold when it is used in ways its designers did not picture. Nothing here is a malformed request: every input is valid, every step is a real step, and the defect is that the application permitted a sequence or a value that its own rules should have refused.
What an attacker is trying to achieve
The attacker is not looking for an interpreter to reach. They want the discount applied twice, the approval skipped, the negative quantity accepted, the workflow completed without the step that costs them something. These findings map directly onto money or obligation, which is why they matter out of proportion to their technical difficulty.
Test cases
8 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
WEB-BUSL-01 Business Logic Data Validation
Objective — Determine whether values that are syntactically valid but commercially impossible are accepted and acted upon.
How it is tested — For every field carrying a quantity, price, date, duration or entitlement, submit values at and beyond the boundaries the business rules imply: negative and zero quantities, prices below cost, dates in the past or implausibly far ahead, durations exceeding any real term. Submit them through the API rather than the interface, since client-side constraints are frequently the only ones present. Follow each accepted value through to its downstream effect rather than stopping at the response.
Prerequisites — The intended ranges stated by the operator; a non-production environment; the ability to observe downstream effects such as invoices or stock levels.
Indicators — A commercially impossible value accepted and persisted; validation present in the interface and absent from the API; a downstream document produced from an impossible value.
Coverage — WSTG-BUSL-01V5.1.3CWE-20CWE-841
Depth — Manual Requires knowing what the business considers possible, which is not derivable from the request.
WEB-BUSL-02 Ability to Forge Requests
Objective — Determine whether a caller can construct a request the interface would never produce, and have the application treat it as legitimate.
How it is tested — Identify parameters the interface always sends fixed or hidden — prices, identifiers, state markers, feature flags, role hints — and vary each. Add fields the interface never sends but the model plausibly contains. Remove fields the interface always sends, to determine what the server assumes when they are absent. Establish whether the server re-derives these values from its own records or accepts what it is given.
Prerequisites — Captured requests for each workflow; knowledge of the data model inferred from responses; a non-production environment.
Indicators — A hidden or fixed value honoured when altered; an unexpected field accepted and acted on; a removed field defaulting to something more permissive than intended.
Coverage — WSTG-BUSL-02V5.1.2CWE-602CWE-915
Depth — Manual The productive fields are specific to this application's model and are inferred, not enumerated.
WEB-BUSL-03 Integrity Checks
Objective — Determine whether data the application trusts as unaltered can in fact be altered by the caller between the point it is issued and the point it is consumed.
How it is tested — Identify values that round-trip through the client — signed tokens, encoded state, hidden totals, references to prior steps. Alter each and resubmit, and where a signature or checksum is present, test whether it is verified at all, whether verification can be skipped by removing it, and whether an algorithm the caller selects is honoured. Establish whether records that should be append-only can be modified or deleted through any route.
Prerequisites — A workflow that carries state through the client; the ability to decode and re-encode that state; a non-production environment.
Indicators — Altered round-tripped state accepted; a signature not verified, removable, or verified with a caller-chosen algorithm; an append-only record modified.
Coverage — WSTG-BUSL-03CWE-345CWE-347
Depth — Manual Recognising which opaque blob carries trusted state is the whole difficulty, and it is specific to the application.
WEB-BUSL-04 Process Timing
Objective — Determine whether the time a process takes, or the order in which its steps arrive, can be used to gain an advantage or to infer information.
How it is tested — Measure response timing across operations that succeed and fail for different reasons, to establish whether timing distinguishes cases the response text does not. Separately, submit the steps of a multi-step workflow out of order and simultaneously, to determine whether the application enforces sequence or merely presents it. Test whether a long-running operation can be observed or interrupted part-way to leave an advantageous partial state.
Prerequisites — A multi-step workflow; the ability to issue concurrent requests; a non-production environment; enough repetitions for timing to be read as signal rather than noise.
Indicators — Timing distinguishing outcomes the response conceals; steps accepted out of order; a partial state that is advantageous and persists; concurrent submissions both succeeding where one should.
Coverage — WSTG-BUSL-04V11.1.6CWE-208CWE-367
Depth — Manual Ordering and concurrency are not part of a scanner's request model.
WEB-BUSL-05 Replay Attack
Objective — Determine whether a request that should take effect once can be submitted repeatedly and take effect each time.
How it is tested — Capture requests whose effect should be singular — payment, redemption, submission, approval, invitation acceptance — and resubmit each verbatim. Establish whether the application recognises the repetition by a nonce, an idempotency key or a state check, and whether that recognition survives concurrent rather than sequential replay. Repeat after the originating session has ended, to determine whether the request stands alone.
Prerequisites — Captured singular-effect requests; a non-production environment; the ability to issue concurrent duplicates.
Indicators — A singular operation taking effect more than once; a nonce accepted twice; concurrent duplicates both succeeding; a captured request succeeding after its session ended.
Coverage — WSTG-BUSL-02V11.1.4CWE-294CWE-837
Depth — Manual The judgement is which operations are supposed to be singular, which comes from the business rules rather than the protocol.
WEB-BUSL-06 Circumvention of Workflows
Objective — Determine whether a workflow can be completed without performing the steps that constrain it, by entering at a later stage or skipping a required one.
How it is tested — Map each workflow's steps and the state each is meant to establish. Request later steps directly without completing earlier ones, and complete the terminal step with state assembled by hand. Establish whether the server verifies that prior steps occurred or infers it from client-supplied state. Include workflows spanning roles, where one party's approval is the constraint, and test whether the requester can supply it.
Prerequisites — The intended step sequence stated by the operator; accounts for each role in a multi-party workflow; a non-production environment.
Indicators — A terminal step succeeding without its predecessors; a required approval supplied by the party it constrains; state assembled by hand accepted as evidence of a completed step.
Coverage — WSTG-BUSL-06V11.1.1V11.1.2CWE-841
Depth — Manual There is no signature for a skipped step; it is only visible against the intended sequence.
WEB-BUSL-07 Abuse of Functionality
Objective — Determine whether a feature working exactly as designed can be used at a scale or in a direction that harms the operator or a third party.
How it is tested — Identify features that consume a resource, contact a third party, or act on someone else's behalf: invitations, notifications, exports, searches, referral and reward mechanisms, and anything that sends mail on a caller's instruction. Establish whether any limit applies per account, per address and per period. Determine whether the feature can be aimed at an arbitrary recipient, and whether attacker-supplied content travels with it.
Prerequisites — An account able to invoke each feature; a controlled recipient address; a non-production environment; agreement on volumes that may be generated.
Indicators — No rate or volume limit on a resource-consuming feature; a message delivered to an arbitrary recipient on the caller's instruction; attacker-supplied content carried in a message the operator's domain sends.
Coverage — WSTG-BUSL-05WSTG-BUSL-07V11.1.4CWE-799CWE-770
Depth — Manual Nothing malfunctions, so there is nothing for a scanner to detect; the finding is a judgement about scale and direction.
WEB-BUSL-08 File Upload Vulnerabilities
Objective — Determine whether the application constrains what may be uploaded, where it is stored, and what happens when it is later retrieved or processed.
How it is tested — Submit files whose extension, declared type and content disagree, and establish which the application trusts. Test whether uploads land in a location from which they can be requested, and whether they are served with a content type that causes the browser to render rather than download them. Submit structured formats that the server will parse, and archives whose entries carry traversal paths. Establish whether size and count are bounded.
Prerequisites — Upload functionality; a non-production environment; the ability to request the stored file afterwards; permission, since some payloads are processed server-side.
Indicators — A file accepted on a mismatched declared type; an upload retrievable and rendered rather than downloaded; an archive entry written outside its directory; a parsed format triggering server-side resolution.
Coverage — WSTG-BUSL-08WSTG-BUSL-09V12.2.1V12.1.1CWE-434CWE-22
Depth — Hybrid Type-confusion probes automate; the archive-traversal and parse-on-server chains are constructed by hand.
What we need from you
A written description of what the workflows are supposed to enforce, because a logic defect is only visible against intent; accounts at each role involved in a multi-party workflow; a non-production environment where transactions may be completed and reversed; and agreement on which workflows may be driven to completion.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- WSTG-BUSL-01 — Test Business Logic Data Validation
- V5.1.3 — Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists).
- CWE-20 — Improper Input Validation
- CWE-841 — Improper Enforcement of Behavioral Workflow
- WSTG-BUSL-02 — Test Ability to Forge Requests
- V5.1.2 — Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar.
- CWE-602 — Client-Side Enforcement of Server-Side Security
- CWE-915 — Improperly Controlled Modification of Dynamically-Determined Object Attributes
- WSTG-BUSL-03 — Test Integrity Checks
- CWE-345 — Insufficient Verification of Data Authenticity
- CWE-347 — Improper Verification of Cryptographic Signature
- WSTG-BUSL-04 — Test for Process Timing
- V11.1.6 — Verify that the application does not suffer from "Time Of Check to Time Of Use" (TOCTOU) issues or other race conditions for sensitive operations.
- CWE-208 — Observable Timing Discrepancy
- CWE-367 — Time-of-check Time-of-use (TOCTOU) Race Condition
- V11.1.4 — Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks.
- CWE-294 — Authentication Bypass by Capture-replay
- CWE-837 — Improper Enforcement of a Single, Unique Action
- WSTG-BUSL-06 — Testing for the Circumvention of Work Flows
- V11.1.1 — Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps.
- V11.1.2 — Verify that the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.
- WSTG-BUSL-05 — Test Number of Times a Function Can Be Used Limits
- WSTG-BUSL-07 — Test Defenses Against Application Misuse
- CWE-799 — Improper Control of Interaction Frequency
- CWE-770 — Allocation of Resources Without Limits or Throttling
- WSTG-BUSL-08 — Test Upload of Unexpected File Types
- WSTG-BUSL-09 — Test Upload of Malicious Files
- V12.2.1 — Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.
- V12.1.1 — Verify that the application will not accept large files that could fill up storage or cause a denial of service.
- CWE-434 — Unrestricted Upload of File with Dangerous Type
- CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.