Business logic flaws are vulnerabilities that exist not because of a coding mistake, but because the application trusts its own workflow too much. Instead of exploiting a buffer overflow or injecting code, attackers simply skip steps, repeat actions, or change the order of requests to get outcomes the app never intended. This kind of flaw is common in multi-step processes like account upgrades, order flows, approval chains, and access control checks. Payment bypass is one well-known example, but the same root cause appears across many different features.
Ethical Considerations
- Only test systems you own or have written permission to test
- Use local labs or bug bounty programs with clear scope
- Do not use these techniques against production systems without authorization
- Report findings responsibly to the application owner
Understanding Logic Flaw Workflows
Logic flaws happen when applications trust the order of steps instead of verifying each action on the server side. Attackers can skip, repeat, or reorder requests to reach states the application assumed were impossible to reach.
Common scenarios where this shows up:
- Payment bypass: skip a payment step to get paid features for free
- Privilege escalation: access an admin endpoint by navigating to it directly
- Order manipulation: change item quantities or prices in a multi-step checkout
- Approval skipping: jump past a review or verification step in a workflow
The example below uses a payment bypass to show how this works. The application has a three-step upgrade process: select a plan, submit payment, then confirm activation. The confirmation endpoint does not verify that payment was actually completed before granting Pro status.
The diagram shows how an attacker can skip step 2 by requesting the confirmation endpoint directly.
Exploiting the Missing Payment Check
The vulnerable code assumes that if a user reaches the confirmation page, they must have paid. It grants Pro status without checking for a valid transaction.
// /upgrade/confirmed.php
// Logic flaw: The code assumes if you are here, you must have paid.
$user_id = $_SESSION['user_id'];
// Directly updating the database to 'pro' status
$sql = "UPDATE users SET membership = 'pro' WHERE id = '$user_id'";
$db->query($sql);
echo "Congratulations! You are now a Pro member.";
An attacker can bypass the payment step by sending a direct request to the confirmation endpoint:
curl http://<target-ip>/upgrade/confirmed
The server processes the request and updates the user's membership to pro without any payment verification. The database now shows the user has Pro status even though no transaction occurred.
Remediation
Verify payment completion on the server side before granting access. Check for a valid transaction ID or payment status in the database before updating membership.
// /upgrade/confirmed.php (fixed)
$user_id = $_SESSION['user_id'];
// Check for a completed payment transaction using a prepared statement
$stmt = $db->prepare(
"SELECT id FROM transactions WHERE user_id = ? AND status = 'completed' ORDER BY created_at DESC LIMIT 1"
);
$stmt->bind_param('i', $user_id);
$stmt->execute();
$transaction = $stmt->get_result()->fetch_assoc();
if (!$transaction) {
http_response_code(403);
echo "Payment required.";
exit;
}
// Only grant Pro status after verifying payment
$update = $db->prepare("UPDATE users SET membership = 'pro' WHERE id = ?");
$update->bind_param('i', $user_id);
$update->execute();
echo "Congratulations! You are now a Pro member.";
The fixed version checks for a completed transaction before updating membership. Direct requests without payment now return a 403 error.
Summary
Business logic flaws are hard to catch with automated scanners because they require understanding what the application is supposed to do. The attacker does not break the code, they just use it in an unintended order. Always validate state on the server side for every critical action, not just at the final step. Test your systems by trying to skip steps, replay requests out of order, or change values between steps to find these gaps before attackers do.
If you found this helpful, drop a like and share it with someone learning security. If you have questions, ran into something different in your own lab, or want to share your results, leave a comment below. Always happy to connect and talk about security, recon techniques, or anything AppSec related.
Feel free to connect with me on LinkedIn
Always open to connecting with people in security, development, or both. Whether you are building something, breaking something, or just getting started, feel free to reach out.
