What Is a Business Logic Vulnerability? UK Examples and How to Find Them

The Vulnerability That Automated Scanners Miss

Every security guide talks about SQL injection, XSS, and missing HTTP headers. Those vulnerabilities are well-understood, well-documented, and — crucially — well-detected by automated scanners. They are also, in many modern applications, relatively rare because frameworks handle the dangerous operations safely by default.

Business logic vulnerabilities are different. They do not look like SQL injection. They do not trigger a scanner signature. They arise from the specific way your application is supposed to work, and attackers exploit them by making your application do exactly what it was designed to do — just not in the way you intended.

What Is a Business Logic Vulnerability?

A business logic vulnerability is a flaw in the rules, sequences, or assumptions that govern how an application operates. The vulnerability exists not in the underlying technical implementation, but in the design of the workflow itself.

Consider a simple example: an e-commerce checkout flow that applies a discount code at step two, then calculates the total at step three. If the application recalculates the total but does not re-validate the discount eligibility at step three, an attacker can apply a one-time discount code, navigate back, and apply it again — receiving a discount they were only entitled to use once.

The code is technically correct at each step. The database query is parameterised. The session is managed properly. The vulnerability is in the sequence of operations and the assumption that users move through the flow in the intended order.

Real-World Examples of Business Logic Flaws

Price Manipulation in E-commerce

An online retailer’s API accepts a product ID and quantity when adding items to a cart. The price is looked up server-side. But what happens if an attacker sends a negative quantity?

In several documented cases, applications subtracted items from the cart total — allowing attackers to effectively receive credit by adding a product with quantity -1. The total went negative, and the checkout allowed completion with a negative payment.

This was not a SQL injection or an XSS. It was the application’s own arithmetic working as programmed, against its own interests.

Account Takeover via Password Reset Race Condition

A password reset flow generates a token, emails it, and invalidates it once used. In a race condition vulnerability, an attacker who receives the token can make two simultaneous requests to use it — the first request passes validation before the second request has caused invalidation, meaning both succeed.

The attacker changes the password with the first request. The legitimate user’s reset email also works because the invalidation has not propagated. Now two people have reset the account’s password. Depending on timing, the attacker controls the account.

Bypassing Subscription Limits

A SaaS application allows users on a free plan to create up to three projects. The limit is enforced on the project creation endpoint. But the API also has an endpoint to duplicate an existing project — and that endpoint does not check the plan limit.

An attacker on a free plan creates three projects, then duplicates them repeatedly via the duplication endpoint. They now have unlimited projects on a free account. The application did exactly what the endpoint was designed to do; the flaw was that the business rule (free plan = three projects maximum) was not consistently applied across all code paths.

UK Financial Services: Transfer Limit Bypass

A UK digital bank allows customers to transfer up to £500 per day without additional authentication. The check runs at transfer initiation. If a customer initiates two transfers simultaneously — each below £500 but together above the limit — both may complete if the limit check reads the current day’s total before either transfer is committed.

This is a classic time-of-check to time-of-use (TOCTOU) race condition applied to a business rule. The financial institution’s rule was correct; the implementation assumed sequential operations.

Why Business Logic Vulnerabilities Are Hard to Find

They require understanding of intent. An automated scanner does not know that a negative quantity is wrong. It sends payloads and looks for error signatures, SQL data leakage, or script execution. It has no model of what your application is supposed to do.

They require multi-step interaction. Many business logic flaws only appear when steps are performed out of order, repeated, or combined in unusual sequences. A scanner that tests each endpoint independently will never discover a vulnerability that requires steps A, B, and C in the wrong order.

They are application-specific. A generic scanner can look for SQL injection on any application because SQL injection follows known patterns. A business logic flaw in a property auction platform requires understanding how property auctions work and what constitutes an invalid bid state.

How Business Logic Vulnerabilities Are Found

**Manual penetration testing** is the primary method. A skilled tester reads your application’s documentation, maps its workflows, identifies assumptions the developers made, and deliberately violates those assumptions.

They ask: what happens if I skip step two? What happens if I repeat step three? What happens if I send a negative value where a positive integer is expected? What happens if I perform actions in parallel that should be sequential?

**Code review** catches these during development. A security-aware developer reviewing a discount application function asks whether the discount eligibility is re-validated at every point where the total is recalculated.

**Threat modelling** during design identifies assumptions that will become vulnerabilities. If a threat model question is “what happens if a user submits this form twice simultaneously?”, the race condition gets caught before code is written.

Reducing Business Logic Risk in UK Applications

**Enforce rules at every layer.** A business rule should not live only in the UI or only in a single API endpoint. If free accounts are limited to three projects, that limit should be checked at every code path that creates or duplicates a project — not just the “new project” form.

**Validate state server-side at every transition.** Do not trust that users arrived at step three via step two. Re-validate that the conditions for step three are still met when step three is requested.

**Use database transactions for multi-step operations.** If two operations must both succeed or both fail, wrap them in a transaction. This eliminates many race condition vulnerabilities by making the multi-step operation atomic.

**Log and alert on unexpected sequences.** If your application sees a checkout completion request without a prior cart validation request in the session, that is anomalous. Logging unusual sequences helps detect exploitation attempts.

**Test adversarially.** Before launch, have someone who was not involved in building the feature try to break it. They should not have the same mental model of how it works, which is exactly the perspective that finds logic flaws.

Automated scanning, including Yrzo AI’s scanner, catches the technical vulnerability classes — SQL injection, XSS, authentication flaws, security misconfiguration. For business logic vulnerabilities in complex applications, manual testing by someone who understands your domain is the necessary complement.