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. 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: 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. 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. 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. 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.