13 Business Logic & Workflow Security Assessment

Mission Overview

Welcome to Lab 13 — Business Logic & Workflow Security Assessment.

In Lab 12, you assessed whether the API consistently enforced authentication, authorization, schemas, data exposure controls, and rate limits.

Now you will move beyond individual endpoints and parameters and assess something more subtle:

Whether the application’s legitimate workflow can be used in an unintended way.

Business logic weaknesses often do not look like classic technical vulnerabilities.

The application may have:

valid authentication
correct authorization
safe input validation
secure sessions
protected APIs

and still permit an unintended business outcome because the server trusts:

workflow order
client-provided values
repeated actions
stale state
missing prerequisite checks
assumptions about user behavior

Mission Goal: Map an authorized business workflow, identify its expected state transitions and trust decisions, then safely test whether a user can manipulate sequence, state, values, or workflow assumptions to produce an unintended outcome.

Mission Information

Item	Details
Difficulty	Intermediate–Advanced
Estimated Time	150–180 minutes
Primary Skill	Business Logic Security
Secondary Skill	Workflow & State Analysis
Environment	GoHackersCloud Web Pentesting Lab
Testing Mode	Controlled Workflow Manipulation
Primary Outcome	Business Logic & Workflow Security Report
Safety Level	Authorized Training Workflows Only

Learning Objectives

By completing this lab, you will be able to:

map multi-step application workflows
identify workflow states
identify server-side prerequisites
identify trust decisions
distinguish workflow logic from authorization
establish normal transaction baselines
assess step-order enforcement
assess skipped workflow steps
assess repeated actions
assess replay behavior
evaluate stale workflow state
assess client-controlled business values
assess quantity and value boundaries
identify inconsistent validation between workflow stages
assess approval workflows
assess cancellation and refund-style state transitions conceptually
evaluate role-dependent workflows
identify duplicate transaction risks
assess idempotency controls
understand race-condition risk without unsafe concurrency testing
assess business impact
preserve and restore lab state
document evidence-backed findings

Core Methodology

Use:

Map Workflow → Establish Intended State → Identify Trust Decisions → Change One Assumption → Observe Transition → Validate Impact → Restore State → Report

Expanded:

Identify Business Process
        │
        ▼
Map Normal Workflow
        │
        ▼
Identify States
        │
        ▼
Identify Preconditions
        │
        ▼
Identify Trust Decisions
        │
        ▼
Capture Valid Baseline
        │
        ▼
Change One Workflow Assumption
        │
        ├── Step Order
        ├── State
        ├── Value
        ├── Repetition
        ├── Role
        └── Timing
        │
        ▼
Observe Server Decision
        │
        ▼
Validate Business Impact
        │
        ▼
Restore Test State
        │
        ▼
Evidence & Report

The core principle is:

A user can be fully authenticated and authorized yet still abuse a workflow if the server fails to enforce the business rules that make the transaction valid.

Part 1 — Confirm Scope

Record:

ASSESSMENT ID:
GHC-WEB-LAB13-001

APPLICATION:

BASE URL:

AUTHORIZED:
Yes

TEST ACCOUNTS:

AUTHORIZED ROLES:

AUTHORIZED WORKFLOWS:

AUTHORIZED TEST OBJECTS:

EXCLUDED TRANSACTIONS:

TEST WINDOW:

Only use dedicated lab workflows and training data.

Part 2 — Create the Lab Workspace

Create:

Web-Pentesting-Labs/
└── Lab-13/
    ├── 01-Scope/
    ├── 02-Workflow-Inventory/
    ├── 03-State-Models/
    ├── 04-Baselines/
    ├── 05-Preconditions/
    ├── 06-Step-Ordering/
    ├── 07-Replay/
    ├── 08-Duplicate-Actions/
    ├── 09-Business-Values/
    ├── 10-Approval-Flows/
    ├── 11-Role-Flows/
    ├── 12-State-Transitions/
    ├── 13-Race-Awareness/
    ├── 14-Positive-Controls/
    ├── 15-Evidence/
    ├── 16-Findings/
    └── 17-Report/

Part 3 — Identify Business Workflows

Examples may include:

Registration

Profile Verification

Checkout

Order Submission

Coupon Application

Subscription Upgrade

Subscription Cancellation

Password Recovery

Expense Approval

Document Approval

Ticket Escalation

Report Generation

Account Closure

Choose one or more intentionally designed training workflows.

Part 4 — Create the Workflow Inventory

Workflow ID	Workflow	Purpose	Role
WF-001	Training Checkout	Complete lab purchase	User
WF-002	Document Approval	Approve training record	Reviewer
WF-003	Subscription Change	Modify lab plan	User

Part 5 — Map the Intended Workflow

Example:

Select Training Item
        │
        ▼
Add to Cart
        │
        ▼
Review
        │
        ▼
Apply Training Discount
        │
        ▼
Confirm
        │
        ▼
Create Order
        │
        ▼
Order Complete

Record each step.

Part 6 — Create the Workflow Step Register

WORKFLOW ID:

STEP 01:

ENDPOINT:

METHOD:

EXPECTED INPUT:

EXPECTED STATE BEFORE:

EXPECTED STATE AFTER:

SERVER DECISION:

NEXT STEP:

Part 7 — Build the State Model

A workflow is often easier to assess as states.

Example:

CREATED
   │
   ▼
PENDING
   │
   ▼
APPROVED
   │
   ▼
COMPLETED

Possible alternative transitions:

PENDING
   │
   ├── CANCELLED
   └── REJECTED

Part 8 — Create the State Register

State	Meaning	Allowed Next State
Created	Transaction exists	Pending
Pending	Awaiting approval	Approved/Rejected
Approved	Authorized	Completed
Completed	Final	None

Part 9 — Identify Preconditions

For every sensitive workflow step, ask:

What must already be true before the server should permit this action?

Examples:

User authenticated

Correct role assigned

Object belongs to user

Previous step completed

Approval exists

Payment state valid

Quantity within policy

Training coupon unused

Record still active

Part 10 — Create the Preconditions Register

Action	Preconditions
Complete order	Valid pending order
Approve request	Reviewer role + pending state
Cancel transaction	Owner + cancellable state
Apply coupon	Valid coupon + policy satisfied

Part 11 — Identify Trust Decisions

A trust decision is where the application decides something important.

Examples:

Total amount

Discount amount

Account tier

Approval status

Quantity

Eligibility

Ownership

Transaction state

Completion status

Create:

Trust Decision	Source	Should Server Verify
Price	Server	Yes
Quantity	Client + server validation	Yes
Approval status	Server	Yes
Owner	Authenticated identity	Yes

Part 12 — Identify Client-Controlled Business Fields

Potential fields include:

price

total

discount

quantity

status

plan

tier

approval

owner_id

currency

Their presence alone does not mean vulnerability.

The question is whether the server trusts them improperly.

Part 13 — Establish a Normal Workflow Baseline

Complete the workflow once exactly as intended.

Record:

NORMAL WORKFLOW BASELINE

Workflow:

User:

Role:

Initial State:

Steps Completed:

Final State:

Expected Outcome:

Observed Outcome:

Evidence:

Part 14 — Capture Important Requests

For each major transition record:

Step

Endpoint

Method

Object ID

Business fields

State before

State after

Response

This becomes your comparison baseline.

Part 15 — Build the Workflow Baseline Matrix

Step	State Before	Action	State After
1	None	Create	Created
2	Created	Submit	Pending
3	Pending	Approve	Approved
4	Approved	Complete	Completed

Part 16 — Test Step Ordering

A workflow may assume users follow the UI sequence.

Server-side enforcement must not rely on that assumption.

Using only the lab workflow, determine whether a later step rejects requests when required earlier steps have not occurred.

Record:

STEP ORDER TEST

Target Step:

Required Previous Step:

Previous Step Completed:
No

Request Result:

State Changed:
Yes / No

Outcome:

Server Enforcement:
Effective / Weak / Inconclusive

Part 17 — Understand Workflow Skipping

Conceptually:

Expected:

A → B → C → D

Potential weakness:

A ─────────► D

The important question is whether D requires state established by B and C and whether the server verifies it.

Part 18 — Create the Step-Order Register

Attempt	Expected Path	Tested Transition	Result
SO-001	Created→Pending	Created→Completed
SO-002	Pending→Approved	Pending→Completed

Part 19 — Do Not Confuse Hidden Steps with Security

A step absent from the UI is not necessarily protected.

Likewise:

UI Sequence ≠ Server-Enforced Workflow

Always validate server-side state transitions.

Part 20 — Assess Repeated Actions

Some functions should occur only once.

Examples:

Redeem training code

Submit approval

Claim training reward

Finalize transaction

Apply single-use adjustment

Using a reversible lab process, submit the action normally and then repeat it once.

Record:

REPEAT ACTION TEST

Action:

First Result:

Second Result:

Duplicate Accepted:
Yes / No

State Changed Twice:
Yes / No

Expected Behavior:

Part 21 — Understand Replay

Replay means reusing a previously valid request after its intended transaction has already occurred.

Conceptually:

Valid Request
     │
     ▼
Transaction Complete

Same Request Again
     │
     ▼
Should Server Accept?

It depends on the operation.

Part 22 — Assess Replay Safely

Use a low-impact training transaction.

Record:

REPLAY TEST

Original Transaction:

Original Request ID:

State After First Request:

Request Replayed:
Yes

Second Outcome:

Unexpected Duplicate Effect:
Yes / No

Part 23 — Understand Idempotency

An idempotent operation should have the same intended result if repeated.

For example, conceptually:

Set status = active

may remain active if repeated.

But:

Create payment

or:

Issue reward

may require duplicate-prevention controls.

Part 24 — Create the Idempotency Register

Operation	Should Be Repeatable	Result
View record	Yes
Update same value	Usually
Create transaction	Policy dependent
Apply one-time action	No

Part 25 — Assess Duplicate Submission Protection

Using normal lab interaction, evaluate whether rapid accidental duplicate submission could create multiple records.

Do not send high-volume requests.

A simple controlled second submission is sufficient.

Part 26 — Assess Client-Controlled Price or Amount Fields

If the lab transaction includes:

unit_price

total

discount

amount

determine whether authoritative values are calculated by the server.

A safer model:

Product ID
    │
    ▼
Server Retrieves Price
    │
    ▼
Server Calculates Total

rather than trusting a client-supplied total.

Part 27 — Create the Business Value Register

FIELD:

WORKFLOW:

CLIENT SUPPLIED:
Yes / No

EXPECTED AUTHORITY:
Client / Server

SERVER RECALCULATES:
Yes / No / Unknown

SECURITY RELEVANCE:

Part 28 — Validate Business Values Safely

Where the lab intentionally permits controlled value testing, use harmless training values.

Test only a small variation.

Record:

BUSINESS VALUE TEST

Field:

Baseline:

Controlled Variation:

Server Accepted:

Final Stored/Calculated Value:

Unexpected Business Outcome:
Yes / No

Do not create financial loss or manipulate real payment systems.

Part 29 — Assess Quantity Boundaries

Training workflows may contain:

quantity

Validate harmless boundary values such as:

0

1

documented maximum

if permitted.

Do not use extreme values.

Part 30 — Create the Quantity Register

Value	Expected	Observed
0	Reject/Policy
1	Accept
Maximum	Accept
Above documented maximum	Reject

Part 31 — Assess Negative Values Conceptually

A negative value may be inappropriate for certain business fields.

If the lab explicitly includes this condition, use only a harmless training object and record server behavior.

Do not test real financial applications.

Part 32 — Assess Discount or Coupon Logic

If the training workflow includes lab discounts, examine:

Eligibility

Usage count

Expiration

Applicable items

Minimum value

Maximum discount

Single-use rules

Record:

DISCOUNT CONTROL PROFILE

Code:

Authorized Lab Code:

Eligibility:

Single Use:

Expiration:

Server Validated:

Final Adjustment:

Part 33 — Test Reuse of a Single-Use Training Code

Use the designated lab code only.

Record:

COUPON REUSE TEST

First Use:

Second Use:

Second Use Accepted:
Yes / No

Duplicate Benefit:
Yes / No

Part 34 — Assess Value Recalculation

If an application calculates a total at one step and later receives it from the client again, determine whether the server recalculates the authoritative value.

Conceptually:

Cart
 │
 ▼
Server Total = 100
 │
 ▼
Client Confirmation
 │
 ▼
Server Recalculates = 100

is safer than trusting an old client-supplied number.

Part 35 — Assess Stale State

Workflows can change between steps.

Example:

Step 1:
Object is valid

Step 2:
Object state changes

Step 3:
Old request still submitted

The server should revalidate security-relevant prerequisites.

Part 36 — Create the Stale-State Register

STALE STATE TEST

Workflow:

State at Request Creation:

State Changed Before Submission:

Submitted Old Request:

Result:

Prerequisite Revalidated:
Yes / No

Use only lab-controlled state changes.

Part 37 — Assess Cancelled or Expired Objects

If the lab has:

Cancelled

Expired

Closed

Revoked

states, verify that previous actions cannot still be completed improperly.

Example:

Pending
   ↓
Cancelled
   ↓
Complete?

Expected outcome is usually denial.

Part 38 — Assess Approval Workflows

Example:

Employee
   │
   ▼
Submit
   │
   ▼
Manager
   │
   ▼
Approve

Map:

submitter
approver
current state
approved action
final action

Part 39 — Build the Approval Matrix

Action	Submitter	Approver
Create request	Allow	Policy
Approve own request	Policy
Approve another request	No	Yes
Complete without approval	No	No

Part 40 — Assess Separation of Duties

Where the lab specifically implements separate roles, verify that business actions requiring independent approval cannot be completed by the same lower-privileged identity unless policy permits it.

Do not create unauthorized roles.

Part 41 — Assess Self-Approval Safely

If the training workflow is intentionally designed for this test:

Submit request as User A
        │
        ▼
Attempt approval as User A

Record:

SELF-APPROVAL TEST

Submitter:

Expected Approver Role:

Approval Attempt:

Result:

State Changed:
Yes / No

Part 42 — Assess Approval Replay

Once approved, determine whether replaying the same approval request causes another business effect.

Again, use only one controlled replay.

Part 43 — Assess State Transition Enforcement

For each workflow state, list allowed actions.

Example:

State	Submit	Approve	Cancel	Complete
Created	Yes	No	Yes	No
Pending	No	Yes	Yes	No
Approved	No	No	Policy	Yes
Completed	No	No	No	No

Then validate selected high-risk transitions.

Part 44 — Create the State Transition Test Register

Current State	Requested Action	Expected
Created	Complete	Deny
Pending	Complete	Deny
Approved	Complete	Allow
Completed	Complete again	Deny/No duplicate effect

Part 45 — Assess Terminal States

A terminal state might be:

Completed

Cancelled

Closed

Rejected

Determine whether the application permits inappropriate transitions out of terminal states.

Part 46 — Assess Object Reuse

Some completed or consumed business objects should not be reusable.

Examples:

One-time token

Invitation

Approval record

Training coupon

Completion action

Record whether reuse is prevented.

Part 47 — Assess Role-Dependent Workflows

Different roles may follow different flows.

Example:

User:
Submit → Wait

Reviewer:
Review → Approve

Admin:
Override under policy

Create:

Workflow Function	User	Reviewer	Admin
Submit	Yes
Approve	No	Yes	Yes/Policy
Override	No	No	Policy

Part 48 — Assess Workflow Authorization Separately

A role may be authorized to call an endpoint but still not be allowed to perform that action in the current state.

For example:

Role Authorization ≠ Workflow Authorization

Both must be enforced.

Part 49 — Assess Multi-Object Workflows

Some transactions combine:

Account

Item

Coupon

Approval

Order

The server should verify that these objects belong to the same valid business transaction.

Part 50 — Create the Object Relationship Register

Object A	Object B	Required Relationship
User	Cart	Owner
Cart	Order	Derived from cart
Coupon	User	Eligible
Approval	Transaction	Same transaction

Part 51 — Assess Cross-Transaction References

Using only dedicated lab objects, determine whether a reference from one training transaction can be reused in another when it should be transaction-specific.

Do not access another real user’s business records.

Part 52 — Assess Workflow Parameter Consistency

The same business value may appear across multiple steps.

Example:

Step 1: plan=basic
Step 2: plan=basic
Step 3: plan=basic

If the client can change it later, the server should enforce current policy.

Part 53 — Build the Workflow Consistency Register

Field	Step 1	Step 2	Step 3	Server Authority
Plan	Basic	Basic	Basic	Server
Quantity	1	1	1	Validated
Total	100	100	100	Server

Part 54 — Assess Server Revalidation

Security-sensitive decisions should often be checked at the point they matter.

For example:

Eligibility at Checkout

should not necessarily rely only on an eligibility decision made much earlier.

Record whether critical conditions are revalidated at completion.

Part 55 — Assess Confirmation Steps

A confirmation page may display:

Item

Quantity

Total

Target account

Do not assume displaying correct information means the server will enforce it.

Capture the actual final request.

Part 56 — Assess Hidden Business Fields

Hidden form fields might contain:

price

discount

account

state

workflow_step

Treat them as client-controlled.

Hidden Field ≠ Trusted Business State

Part 57 — Assess Workflow Step Indicators

An application might send:

step=3

or:

stage=complete

The server should not authorize a transition merely because the client claims the workflow is at that step.

Part 58 — Assess Duplicate Objects

If repeated submission creates two training transactions, determine whether that is intended behavior.

Duplicate records are not automatically vulnerabilities.

Ask whether they cause unintended business impact.

Part 59 — Understand Race Conditions Conceptually

Some business logic weaknesses occur only when multiple requests reach the server close together.

Conceptually:

Check:
Coupon unused
       │
       ├────────────┐
       ▼            ▼
Request A       Request B
       │            │
       ▼            ▼
Use coupon      Use coupon

This can create a check-versus-use problem.

Part 60 — Keep Race Testing Safe

In this lab, focus on:

identifying candidate race-sensitive workflows
understanding atomicity
checking whether duplicate actions are naturally prevented
reviewing response/state behavior

Do not perform high-concurrency flooding.

A dedicated advanced lab can handle controlled concurrency separately.

Part 61 — Create the Race Candidate Register

Operation	Shared State	Duplicate Impact	Candidate
Redeem code	Usage count	Duplicate benefit	Yes
View profile	None	None	No
Create approval	State	Duplicate state change	Maybe

Part 62 — Assess Idempotency Controls

APIs and business workflows may use:

transaction identifier

request identifier

idempotency key

server-side uniqueness rule

Record whether such controls are visible in the lab.

Part 63 — Assess Error Recovery

Consider:

Request partially succeeds
      │
      ▼
Client receives error
      │
      ▼
User retries

Could the retry create a duplicate action?

Use only the provided lab scenario.

Part 64 — Assess Failed-Then-Retry Behavior

Record:

RETRY TEST

Initial Action:

Client Observed Result:

Server State:

Retry Performed:

Duplicate Effect:

Final State:

Part 65 — Identify Positive Business Controls

Examples include:

Server-side price calculation

Strict state transition enforcement

Single-use transaction tokens

Duplicate submission prevention

Approval separation

Eligibility revalidation

Authoritative ownership checks

Idempotency controls

Terminal-state enforcement

Server-side quantity limits

Coupon usage enforcement

Atomic state changes

Document controls that work.

Part 66 — Create the Positive Control Register

Control	Workflow	Result
Server calculates total	Checkout	Effective
Completed state terminal	Order	Effective
Single-use code	Promotion	Effective
Self-approval denied	Approval	Effective

Part 67 — Potential Finding Categories

Possible findings include:

Workflow Step Bypass

Business State Transition Bypass

Client-Controlled Business Value

Duplicate Transaction Processing

Replay of Single-Use Action

Single-Use Control Failure

Approval Workflow Bypass

Self-Approval Weakness

Stale-State Acceptance

Terminal-State Reuse

Cross-Transaction Object Reuse

Insufficient Server Revalidation

Part 68 — Finding Example: Workflow Step Bypass

FINDING ID:
LOGIC-001

TITLE:
Transaction Can Be Completed Without Required Approval Step

SEVERITY:
High
Depending on business impact

CONFIDENCE:
High

WORKFLOW:
Training Approval Process

OBSERVATION:
The application allowed a pending training transaction to move
directly to the completed state even though the required
approval state had not been established.

VALIDATION:
The request was performed against a dedicated lab transaction.
The resulting state changed from Pending directly to Completed.

IMPACT:
Users may bypass a required business approval control.

EVIDENCE:
EV-LOGIC-007

RECOMMENDATION:
Enforce server-side state transition rules and verify that the
required approval exists immediately before processing the
completion action.

Part 69 — Finding Example: Client-Controlled Total

FINDING ID:
LOGIC-002

TITLE:
Server Trusts Client-Supplied Transaction Total

SEVERITY:
High
Depending on workflow

CONFIDENCE:
High

OBSERVATION:
The final training transaction request accepted a client-supplied
total rather than recalculating the authoritative value from
server-controlled item data.

VALIDATION:
A small controlled training-value change resulted in the server
recording the modified total.

IMPACT:
A user may be able to alter a business value that should be
derived and enforced server-side.

LIMITATION:
Only non-financial lab data was used.

RECOMMENDATION:
Calculate authoritative transaction values server-side using
trusted item, pricing, policy, and eligibility data.

Part 70 — Finding Example: Single-Use Action Replayed

FINDING ID:
LOGIC-003

TITLE:
Single-Use Training Benefit Can Be Applied More Than Once

SEVERITY:
Medium / High
Depending on business impact

CONFIDENCE:
High

OBSERVATION:
A single-use lab action was successfully processed a second time
using the previously valid request.

IMPACT:
Controls intended to limit the business operation to one use can
be bypassed.

RECOMMENDATION:
Enforce server-side uniqueness and consume the transaction state
atomically after successful use.

Part 71 — Finding Example: Self-Approval

FINDING ID:
LOGIC-004

TITLE:
Request Submitter Can Approve Their Own Restricted Workflow

SEVERITY:
High
Depending on required separation of duties

CONFIDENCE:
High

OBSERVATION:
The same authorized training identity that created the request
was able to perform the approval step even though the workflow
specified an independent reviewer.

IMPACT:
Required separation of duties can be bypassed.

RECOMMENDATION:
Enforce approver eligibility server-side and prevent the
request owner from satisfying approval requirements where
business policy requires independent review.

Part 72 — Avoid False Findings

Do not report:

Workflow has several steps.

as a vulnerability.

Do not report:

Hidden price field exists.

as price manipulation.

Do not report:

Request can be repeated.

as replay weakness unless it creates an unintended second effect.

Do not report:

User can cancel own training order.

as logic bypass when the policy permits it.

Part 73 — Build the Findings Register

Finding	Status	Severity	Confidence
Step-order enforcement
Replay
Duplicate processing
Client business values
Approval enforcement
State transition
Stale-state handling
Idempotency

Part 74 — Build the Workflow Coverage Matrix

Area	Tested	Result
Workflow inventory	Yes
State model	Yes
Preconditions	Yes
Normal baseline	Yes
Step ordering	Yes
Skipped steps	Yes
Replay	Yes
Duplicate actions	Yes
Business values	Yes/NA
Quantity limits	Yes/NA
Single-use controls	Yes/NA
Stale state	Yes
Approval flow	Yes/NA
Self approval	Yes/NA
State transitions	Yes
Terminal states	Yes
Cross-transaction references	Yes/NA
Idempotency	Yes/NA
Race candidates	Reviewed

Part 75 — Create the Evidence Register

Example:

Evidence ID	Description
EV-LOGIC-001	Normal workflow map
EV-LOGIC-002	Normal successful transaction
EV-LOGIC-003	State transition baseline
EV-LOGIC-004	Step-order test
EV-LOGIC-005	Replayed action
EV-LOGIC-006	Business-value comparison
EV-LOGIC-007	Approval bypass validation
EV-LOGIC-008	Single-use control test
EV-LOGIC-009	Stale-state assessment
EV-LOGIC-010	Restored lab state

Part 76 — Mission Challenge

Complete:

BUSINESS LOGIC & WORKFLOW SECURITY ASSESSMENT

Assessment ID:

Analyst:

Date:


SCOPE

Application:

Authorized:
Yes / No

Test Accounts:

Roles:

Workflow:


WORKFLOW PURPOSE

Business Goal:

Expected User:

Expected Final State:


WORKFLOW MAP

Step 01:

State Before:

Action:

State After:


Step 02:

State Before:

Action:

State After:


PRECONDITIONS

Action 01:

Required State:

Required Role:

Required Object:


TRUST DECISIONS

Decision 01:

Client Controlled:

Server Verified:


NORMAL BASELINE

Initial State:

Final State:

Expected Result:

Observed Result:


STEP ORDER

Tested Transition:

Expected:

Observed:

Unexpected State Change:
Yes / No


REPLAY

Action:

First Result:

Second Result:

Duplicate Effect:
Yes / No


DUPLICATE SUBMISSION

First Transaction:

Second Submission:

Duplicate Object Created:
Yes / No


BUSINESS VALUES

Field:

Authoritative Source:

Baseline:

Controlled Variation:

Server Recalculated:
Yes / No


QUANTITY / RANGE

Minimum:

Maximum:

Invalid Boundary:

Server Enforcement:


SINGLE-USE CONTROL

Object:

First Use:

Second Use:

Reuse Allowed:


STALE STATE

Initial State:

Changed State:

Old Request Submitted:

Result:


APPROVAL

Submitter:

Required Approver:

Self Approval:

Result:


STATE TRANSITIONS

Current State:

Requested State:

Expected:

Observed:


TERMINAL STATE

State:

Repeated Action:

Result:


IDEMPOTENCY

Operation:

Identifier:

Duplicate Prevented:


RACE AWARENESS

Candidate Operation:

Shared State:

Potential Duplicate Effect:

High-Concurrency Test Performed:
No


POSITIVE CONTROLS

Control 01:

Control 02:

Control 03:


FINDINGS

Finding 01:

Severity:

Confidence:

Evidence:


Finding 02:

Severity:

Confidence:

Evidence:


RESTORATION

Test Records Restored:
Yes / No

Lab State Clean:
Yes / No


LIMITATIONS

No real financial transactions were performed.

No high-concurrency race testing was performed.

No production workflows were assessed.

Additional Limitation:


FINAL ASSESSMENT

Workflow Enforcement:
Effective / Weak / Inconclusive

State Validation:

Server-Side Business Validation:

Replay Protection:

Approval Controls:

Duplicate Prevention:

Overall Business Logic Risk:

Ready for Vulnerability Validation & Reporting:
Yes / No

What Not to Do

Do not:

Manipulate real financial transactions

Attempt real payment fraud

Use real coupons or credits

Target real customer records

Create financial loss

Bypass real approval systems

Modify production subscriptions

Flood the application with concurrent requests

Perform high-volume race-condition testing

Create thousands of duplicate transactions

Abuse refund or payout systems

Use another real user's business objects

Leave test transactions in a modified state

Continue after the business-control failure is established

The professional rule is:

Change one business assumption at a time, use only reversible training transactions, prove the unintended outcome, restore the state, and stop.

Professional Distinctions

Always distinguish:

Authenticated User
      ≠
Valid Business Transaction

Authorized Endpoint
      ≠
Authorized Workflow Transition

Hidden Business Field
      ≠
Business Logic Vulnerability

Client-Supplied Price
      ≠
Price Manipulation Until Server Trust Is Proven

Repeated Request
      ≠
Replay Vulnerability Automatically

Duplicate Record
      ≠
Security Impact Automatically

Multi-Step Workflow
      ≠
Step Bypass

Skipped UI Screen
      ≠
Server-Side Workflow Bypass

User Can Approve
      ≠
Self-Approval Weakness Unless Policy Requires Separation

Old Request Accepted
      ≠
Stale-State Vulnerability Without Unintended Outcome

Concurrent Requests Possible
      ≠
Race Condition Proven

Business Logic Weakness
      ≠
Traditional Injection Vulnerability

Evidence Requirements

Capture:

authorization and scope
Workflow Inventory
workflow diagram
State Register
Preconditions Register
Trust Decision Register
client-controlled business fields
normal workflow baseline
transition requests
step-order assessment
skipped-step test
replay assessment
duplicate-action test
idempotency observations
business-value authority
quantity/value boundaries
single-use control assessment
stale-state test
cancelled/expired-state assessment
approval workflow
separation-of-duties assessment
state-transition matrix
terminal-state assessment
cross-transaction relationship checks
server revalidation observations
race candidate review
positive security controls
restoration evidence
findings register
coverage matrix
evidence register

Mission Deliverables

Complete:

scope confirmed
workflow selected
workflow inventory created
normal workflow mapped
state machine documented
prerequisites identified
trust decisions identified
business-relevant client fields identified
normal baseline completed
step-order controls assessed
skipped-step behavior assessed
replay behavior assessed
duplicate-action behavior assessed
idempotency reviewed
server-side business-value authority assessed
quantity/value boundaries reviewed where applicable
single-use controls assessed where applicable
stale-state behavior assessed
cancelled/expired-state behavior assessed
approval workflow reviewed where applicable
separation of duties assessed
state-transition enforcement assessed
terminal states assessed
cross-transaction relationships reviewed
confirmation/finalization step reviewed
server-side revalidation assessed
race-sensitive functions identified
no unsafe concurrency testing performed
positive controls documented
lab state restored
findings validated
severity and confidence assigned
final Business Logic Assessment completed

Lab Report Template

# Lab 13 — Business Logic & Workflow Security Assessment

## Executive Summary

## Mission Objective

## Authorization & Scope

## Business Workflow Inventory

## Workflow Architecture

## State Model

## Preconditions

## Trust Decisions

## Client-Controlled Business Fields

## Normal Workflow Baseline

## Step-Order Enforcement

## Workflow Step Bypass

## Replay Assessment

## Duplicate Submission Assessment

## Idempotency

## Business Value Validation

## Quantity & Range Controls

## Single-Use Controls

## Stale-State Assessment

## Approval Workflow

## Separation of Duties

## State Transition Enforcement

## Terminal States

## Cross-Transaction Relationships

## Server-Side Revalidation

## Race-Condition Awareness

## Positive Security Controls

## Findings

## Severity & Confidence

## Evidence Register

## Restoration & Cleanup

## Limitations

## Recommendations

## Conclusion

Knowledge Check

Question 1 — What makes business logic testing different from ordinary vulnerability testing?

Business logic testing focuses on whether legitimate functionality can be combined, reordered, repeated, or manipulated to create an unintended business outcome.

Question 2 — Can an authenticated and authorized user still exploit a business logic weakness?

Yes.

Many business logic vulnerabilities involve legitimate users performing permitted actions in unintended sequences or states.

Question 3 — Does skipping a UI screen automatically prove a workflow bypass?

No.

The server must fail to enforce a required prerequisite or state transition.

Question 4 — What is replay in a business workflow?

Reusing a previously valid request after its intended one-time transaction or state change has already occurred.

Question 5 — Why should authoritative prices or totals be calculated server-side?

Because client-controlled values can be modified and should not be trusted for sensitive business decisions.

Question 6 — What is a stale-state problem?

The server accepts an action based on old assumptions even though the underlying business state has changed.

Question 7 — Why is separation of duties important?

Some workflows require different identities or roles to perform independent steps, such as submitting and approving a transaction.

Question 8 — Does accepting a repeated request always indicate a vulnerability?

No.

Some operations are intentionally idempotent or repeatable. There must be an unintended additional business effect.

Question 9 — Why avoid high-concurrency race testing in this lab?

Because the goal is to understand and identify race-sensitive business logic without creating unnecessary load or instability.

Question 10 — What is the central question?

“Can a user remain technically authorized while manipulating the order, state, values, or assumptions of a legitimate workflow to achieve an outcome the business did not intend?”

Skills Achieved

After completing this lab, you should understand:

business workflow mapping
application state modeling
prerequisite analysis
trust-decision mapping
step-order enforcement
workflow bypass analysis
replay assessment
duplicate-action assessment
idempotency concepts
server-side business-value validation
quantity and range validation
single-use controls
stale-state analysis
approval workflow security
separation-of-duties assessment
state-transition security
race-condition awareness
evidence-based business logic reporting

Professional Takeaway

A weak business logic assessment looks like:

Find Business Parameter
        ↓
Change Value
        ↓
Application Accepts
        ↓
Report Critical Logic Bug

A professional assessment looks like:

Understand Business Objective
        ↓
Map Workflow
        ↓
Map States
        ↓
Identify Preconditions
        ↓
Identify Server Trust Decisions
        ↓
Establish Normal Transaction
        ↓
Change One Assumption
        ↓
Observe State Transition
        ↓
Verify Business Outcome
        ↓
Repeat Only If Necessary
        ↓
Assess Impact
        ↓
Restore Lab State
        ↓
Evidence
        ↓
Report

What’s Next?

➡️ Lab 14 — Web Vulnerability Validation, Evidence & Reporting

In the next lab, you will stop discovering new vulnerability classes and focus on turning your previous web-testing observations into defensible professional findings.

You will consolidate:

scope and methodology
observation vs finding
reproducibility
evidence quality
request/response preservation
screenshots
affected endpoints
affected identities
technical impact
business impact
severity
confidence
remediation
retest criteria
executive summaries
findings tables
evidence registers
final pentest reporting

The methodology becomes:

Observe → Reproduce → Minimize → Validate → Preserve → Assess → Recommend → Report

The central question will be:

“Can another security professional reproduce each finding, understand exactly why it matters, verify the supporting evidence, and know what must change to remediate it?”