Good pentesters test business logic by learning the system’s intended invariants and then changing actors, sequence, state, values, timing and channels. Automated DAST can identify many request-level weaknesses, but it cannot reliably understand that one person must not initiate and approve the same transaction, or that a discount may be used once per customer.

Manual business-logic testing is structured hypothesis work. The tester models valuable outcomes, maps prerequisites and state transitions, creates controlled identities and data, and then attempts plausible misuse while preserving evidence.

Learn assets, actors and invariants

  • Assets: money, entitlement, access, inventory, data, trust and audit state.
  • Actors: users, peers, approvers, administrators, services and partners.
  • States: invited, pending, approved, consumed, refunded, revoked and archived.
  • Invariants: limits and relationships that must always hold.

Interview workflow owners and review diagrams, API documentation and normal client traffic. Ask for the business consequence of an invalid transition. A tester needs domain meaning without being limited to the happy path.

Build an abuse-case model

  1. Choose a valuable or privileged outcome.
  2. List the legitimate steps and actors required to reach it.
  3. Identify server-side decisions that enforce each prerequisite.
  4. Change one dimension: actor, order, state, value, time or channel.
  5. Predict an observable secure outcome.
  6. Execute safely and verify server-side state.

Prioritize abuse cases by consequence and plausibility. The model should evolve as testers discover hidden states and alternate interfaces.

Manipulate sequence and state

  • Skip a required verification or approval step.
  • Repeat a one-time action or reuse an expired transition token.
  • Perform later steps before prerequisites complete.
  • Return to an earlier state after a final action.
  • Call the API directly when the UI disables an action.

Verify persistent state, not only the immediate response. A rejected client request may still enqueue a job or create a partial record.

Change actors and separation of duties

Use controlled accounts to test whether the same user can create and approve, request and fulfill, grant and consume, or initiate and refund. Substitute peer, role and tenant identities during each transition. Include support and impersonation paths.

Challenge quantities, pricing and limits

  • Negative, zero, excessive and boundary values.
  • Currency, unit, rounding and precision transitions.
  • Client-calculated prices, discounts or totals.
  • Quota resets, duplicate redemption and partial consumption.
  • Bulk operations that bypass per-item limits.

The goal is a protected outcome, not random fuzzing. Confirm which server owns the authoritative calculation and whether downstream systems receive consistent values.

Test concurrency and replay

Send controlled parallel requests to actions that should be atomic or single-use. Examples include redemption, withdrawal, booking, inventory allocation, password reset and approval. Vary timing and observe final state, audit records and downstream jobs.

Use rate and concurrency limits agreed in the rules of engagement. Race testing must not create uncontrolled load or real financial effects.

Cross channels and interfaces

  • Begin in web and finish through API or mobile.
  • Use an older API version after a policy change.
  • Invoke a background or webhook path that trusts prior validation.
  • Modify server state through import or bulk administration.
  • Reuse a token or object created in another tenant context.

Different clients often share business state but implement different validations. Server-side invariants must hold across every channel.

Chain smaller weaknesses

Combine information disclosure, weak identifier controls, invitation behaviour, authorization gaps and workflow logic. A low-impact clue may supply the prerequisite for a material abuse case. Record each link and distinguish executed evidence from inferred possibility.

Use automation as assistance

Automate repetition, boundary generation, concurrency and result comparison after a human defines the hypothesis. DAST can discover endpoints and request-level anomalies. The tester must interpret business state and decide what constitutes unauthorized benefit or loss.

Capture evidence developers can use

  • Intended invariant and legitimate workflow.
  • Actors, roles, tenants and prepared state.
  • Abusive sequence with raw request evidence.
  • Before-and-after authoritative state.
  • Business impact and practical preconditions.
  • Likely root cause, sibling flows and verification criteria.

A screen recording can clarify sequence but should be accompanied by requests, state evidence and stable reproduction steps.

Evaluate a vendor’s claimed manual depth

Ask how the team identifies business invariants, prepares state, records hypotheses and reports negative coverage. Review a sample finding for sequence and state evidence. Tool names do not demonstrate business-logic testing.

The OWASP Web Security Testing Guide includes business-logic testing ideas. Apply them to product-specific assets and workflows rather than treating them as generic payload checks.

Convert discoveries into prevention

Fix the demonstrated path, then encode the invariant in server-side policy, transaction boundaries, idempotency controls and regression tests. Review sibling workflows and alternate clients. Retest the abuse outcome, not only the original endpoint response.

The practical decision

Manual business-logic testing turns domain rules into adversarial hypotheses. Test sequence, state, actors, values, timing and interfaces; verify durable outcomes; and chain evidence where necessary. This work reveals failures that automated DAST cannot infer from isolated requests.

Use WIMD for business-logic-led penetration testing focused on the workflows, invariants and abuse outcomes that matter to your product.