Logic Basics

When Correct Code Fails

Can a perfectly coded application still be broken? Yes, if its business rules allow an unintended outcome.

A business logic flaw appears when implementation disagrees with the application’s intended workflow.

The code may use valid syntax, handle requests correctly, and avoid familiar injection flaws. The design can still make a dangerous assumption.

For bug bounty work, this means reading beyond individual parameters. Ask what the user is allowed to achieve after combining several normal actions.

These vulnerabilities matter because automated scanners rarely understand business intent. Human reasoning is needed to recognize when legitimate steps produce an illegitimate result.

Think in State Machines

A web application can be viewed as a state machine: each action moves an object or account from one state to another.

A shopping cart may move from created, to checked, to payment pending, and finally to completed.

A state transition should occur only when its required conditions are satisfied. The application must verify both the request and the current state.

A flaw appears when the system accepts a transition that should be impossible. For example, it may allow completion while payment remains unverified.

Mapping states makes hidden assumptions easier to see than reading isolated requests.

Compare Intent With Reality

Start by describing the intended workflow in plain language. Write down the expected order of actions and the condition required at each step.

Then observe what the application actually accepts. Compare each request, response, and resulting state with the intended design.

The important gap is often small: a check happens in the interface but not on the back end, or one step assumes another already succeeded.

A visible button sequence does not prove enforcement. A user may be guided through steps A, B, and C while the server quietly accepts A followed by C.

That discrepancy is the core investigation target.

The Payment Bypass Pattern

Consider a workflow that moves a user from a shopping cart to a payment gateway.

The intended sequence is A: create the cart, B: complete payment verification, and C: finalize the order.

A logic flaw exists if the server accepts C immediately after A. The user has followed valid request formats, yet bypassed the required payment step.

The weakness is not necessarily a malformed parameter or injection payload. It is a missing rule connecting the final action to a verified payment state.

When testing, inspect whether each transition checks its prerequisites independently. Never assume the interface sequence represents server enforcement.

Legitimate Actions, Wrong Outcome

Logic flaws often use actions that are individually permitted. The problem emerges when their order, combination, or timing violates the business rule.

A request can be authenticated, correctly formatted, and accepted with a normal response. Those signals do not prove the resulting outcome is authorized.

Look for boundaries between steps. Can a later action run before an earlier verification? Can an object remain usable after its state should have changed?

This approach differs from searching only for technical errors. You are testing whether the application’s decisions remain correct when a user behaves outside the expected path.

The goal is to expose broken assumptions safely.

Follow Session State

Many workflows depend on session integrity, meaning the application consistently remembers what has been verified and what remains incomplete.

This becomes harder when back-end systems process requests across distributed environments. One component may trust a state that another component never confirmed.

Trace the important state through every request, response, and handoff. Identify which system records completion and which system authorizes the next action.

Do not treat a successful page load as proof of completed business logic. The visible result may reflect a client-side assumption.

For a bug bounty report, explain the state mismatch, the reproducible sequence, and the resulting impact.

A Practical Testing Method

Begin with a workflow map. List the states, expected transitions, required checks, and actions that change the outcome.

Next, test the boundaries one transition at a time. Try the expected sequence, then examine whether a later step works without its prerequisite.

Compare server responses and persistent outcomes, not only interface behavior. A page can look correct while the back end records an unsafe state.

Prioritize workflows involving payment, verification, or completion because incorrect transitions can create high-impact results.

The central question is simple: Can a user reach an outcome the design intended to prevent using otherwise legitimate actions?

A business logic flaw occurs when an application's implementation disagrees with its intended _____, even if the underlying code is syntactically correct.

• workflow
• memory layout

Answer: workflow

Business logic flaws stem from discrepancies between intended business rules and actual state machine implementation, not syntax or injection errors.

In a web application state machine, a _____ moves an object between states only when all required _____ are verified by the server.

Answer: In a web application state machine, a state transition moves an object between states only when all required conditions are verified by the server.

State machines require that state transitions occur strictly when required conditions (prerequisites) are verified by the server.

During a bug bounty assessment, a shopping application UI guides users through cart creation (Step A), payment verification (Step B), and order finalization (Step C). How should you test for a logic flaw in this workflow?

• Send the request for Step C directly after Step A to check if the server enforces prerequisite checks.
• Assume the workflow is secure if the interface successfully grays out Step C until Step B finishes.
• Inject SQL control characters into the parameter for Step B to check for database errors.
• Rely entirely on automated scanners to detect whether the order sequence is enforced correctly.

Answer: Send the request for Step C directly after Step A to check if the server enforces prerequisite checks.

User interfaces do not guarantee server-side enforcement. Testing whether Step C succeeds immediately after Step A verifies if the server independently enforces prerequisite states.