Business logic errors occur when code works exactly as written, but the underlying logic itself is flawed in a way that violates the intended security or…
Business logic errors occur when code works exactly as written, but the underlying logic itself is flawed in a way that violates the intended security or functional requirements of the application. Unlike buffer overflows or injection attacks, these vulnerabilities hide in the *design* of the feature, not in unsafe coding practices. An attacker can exploit these flaws to bypass intended controls, manipulate data, or gain unauthorized access.
Business logic errors arise when developers implement a feature without fully considering all possible states, edge cases, or attacker-controlled inputs. The code may correctly execute the intended happy path, but fail to enforce constraints, validate state transitions, or prevent unintended sequences of operations. Common patterns include missing authorization checks between related operations, incorrect assumptions about data consistency, race conditions in multi-step workflows, or failure to validate that a user has the right to perform an action even if they can technically trigger it.
These flaws are particularly dangerous because they often pass code review and testing—the code does what it was asked to do. The vulnerability lies in what was *not* asked for: the missing validation, the unchecked assumption, or the incomplete state machine.
Business logic errors can lead to unauthorized access, financial fraud, privilege escalation, or data manipulation. For example, an attacker might complete a purchase without payment, modify another user's profile, bypass multi-factor authentication through a forgotten-password workflow, or exploit a race condition to double-spend a digital asset. The impact depends entirely on what business process is flawed, but the consequences are often severe because the attacker is working within the application's normal feature set, making detection harder.
def transfer_funds(user_id, recipient_id, amount):
# Fetch user balance
user = db.query("SELECT balance FROM users WHERE id = ?", user_id)
# Check if user has enough funds
if user['balance'] >= amount:
# Deduct from sender
db.execute("UPDATE users SET balance = balance - ? WHERE id = ?",
amount, user_id)
# Add to recipient
db.execute("UPDATE users SET balance = balance + ? WHERE id = ?",
amount, recipient_id)
return "Transfer successful"
else:
return "Insufficient funds"Why it's vulnerable:
The code checks the balance once, then performs two separate updates. Between the check and the deduction, another concurrent request could also pass the balance check, allowing the user to transfer more than they actually have. There is no atomic transaction, no lock, and no re-validation before the final deduction.
def transfer_funds(user_id, recipient_id, amount):
try:
db.begin_transaction()
# Lock and re-fetch balance within transaction
user = db.query(
"SELECT balance FROM users WHERE id = ? FOR UPDATE",
user_id
)
# Re-validate within transaction
if user['balance'] < amount:
db.rollback()
return "Insufficient funds"
# Perform both updates atomically
db.execute("UPDATE users SET balance = balance - ? WHERE id = ?",
amount, user_id)
db.execute("UPDATE users SET balance = balance + ? WHERE id = ?",
amount, recipient_id)
db.commit()
return "Transfer successful"
except Exception as e:
db.rollback()
raise<?php
function approve_discount($user_id, $discount_percent) {
// Check if user is admin
$user = $wpdb->get_row(
$wpdb->prepare("SELECT role FROM users WHERE id = %d", $user_id)
);
if ($user->role === 'admin') {
// Apply discount to all pending orders
$wpdb->query(
$wpdb->prepare("UPDATE orders SET discount = %d WHERE status = 'pending'",
$discount_percent)
);
return "Discount applied";
}
return "Unauthorized";
}
// Called from AJAX endpoint
approve_discount($_SESSION['user_id'], $_POST['discount']);
?>Why it's vulnerable:
The code checks if the user is an admin, but does not verify that the discount percentage is reasonable or that the user intended to apply it to *all* pending orders. An attacker with admin privileges (or who can escalate to admin through another flaw) could apply a 99% discount to all orders, causing financial loss. The logic is missing a constraint check and a confirmation step.
<?php
function approve_discount($user_id, $discount_percent, $order_ids) {
// Check if user is admin
$user = $wpdb->get_row(
$wpdb->prepare("SELECT role FROM users WHERE id = %d", $user_id)
);
if ($user->role !== 'admin') {
return "Unauthorized";
}
// Validate discount is within acceptable range
if ($discount_percent < 0 || $discount_percent > 25) {
return "Discount must be between 0 and 25 percent";
}
// Validate order IDs belong to the user's store and are pending
$placeholders = implode(',', array_fill(0, count($order_ids), '%d'));
$valid_orders = $wpdb->get_col(
$wpdb->prepare(
"SELECT id FROM orders WHERE id IN ($placeholders) AND status = 'pending' AND store_id = %d",
array_merge($order_ids, [$_SESSION['store_id']])
)
);
if (count($valid_orders) !== count($order_ids)) {
return "Invalid order selection";
}
// Apply discount only to validated orders
foreach ($valid_orders as $order_id) {
$wpdb->query(
$wpdb->prepare("UPDATE orders SET discount = %d WHERE id = %d",
$discount_percent, $order_id)
);
}
return "Discount applied to " . count($valid_orders) . " orders";
}
// Called from AJAX endpoint with explicit order list
approve_discount($_SESSION['user_id'], $_POST['discount'], $_POST['order_ids']);
?>Look for unexpected data inconsistencies: users with negative balances, orders that skipped payment, or discounts applied outside normal ranges. Check audit logs for sequences of operations that should not be possible (e.g., a refund before a charge, or a user accessing another user's data). Monitor for repeated failed authorization attempts followed by successful sensitive actions, which may indicate an attacker probing for logic flaws.
