All about: Business Logic Bugs


What are business logic vulnerabilities?

Business logic vulnerabilities are flaws in the design and implementation of an application that allows an attacker to elicit unintended behavior.

How do business logic vulnerabilities arise?

Business logic vulnerabilities often arise because the design and development teams need to make better assumptions about how users will interact with the application.

What is the impact of business logic vulnerabilities?

Fundamentally, the impact of any logic flaw depends on what functionality it is related to. If the flaw is in the authentication mechanism, for example, this could have a serious impact on your overall security.
Attackers could potentially exploit this for privilege escalation, or to bypass authentication entirely, gaining access to sensitive data and functionality. This also exposes an increased attack surface for other exploits.

What are some examples of business logic vulnerabilities?

Excessive trust in client-side controls

A fundamentally flawed assumption is that users will only interact with the application via the provided web interface.

Failing to handle unconventional input

For example, the application may be designed to accept arbitrary values of a certain data type. Still, the logic determines whether or not this value is acceptable from the perspective of the business. Many applications incorporate numeric limits into their logic. This might include limits designed to manage inventory, apply budgetary restrictions, trigger phases of the supply chain, and so on.

$transferAmount = $_POST['amount'];
$currentBalance = $user->getBalance();

if ($transferAmount <= $currentBalance) {
// Complete the transfer
} else {
// Block the transfer: insufficient funds
  • Are there any limits that are imposed on the data?
  • What happens when you reach those limits?
  • Is any transformation or normalization being performed on your input?

Application Logic Errors

For example, let’s say an application implements a three-step login process.
First, the application checks the user’s password.
Then, it sends a MFA code to the user and verifies it.
Finally, the application asks security question before logging in the user.

  1. The user visits The application prompts the user for their password, and the user enters it.
  2. If the password is correctly entered, the application sends an MFA code to the user’s email address and redirects the user to
    Here, the user enters the MFA code.
  3. The application checks the MFA code, and if it is correct, redirects the user to
    There, the application asks the user several security questions and logs in the user if the answers they provided are correct.
POST /new_order
(POST request body)
&payment_id=1 //payment_id parameter refers to the ID of the user’s saved credit card
POST /new_order
(POST request body)
POST /new_order
(POST request body)

Hunting for Application Logic Errors

Step 1: Learn About Your Target

Browse the application as a regular user to uncover functionalities and interesting features.
You can also read the application’s engineering blogs and documentation.

Step 2: Intercept Requests While Browsing

Intercept requests while browsing the site and pay attention to sensitive functionalities.
Take note of how sensitive functionalities and access control are implemented, and how they interact with client requests.

Step 3: Think Outside the Box

Finally, use your creativity to think of ways to bypass access control or otherwise interfere with application logic.
Play with the requests that you have intercepted and craft requests that should not be granted.

Finding Your First Application Logic Error

  1. Learn about your target application. The more you understand about the architecture and development process web application, the better you’ll be at spotting these vulnerabilities.
  2. Intercept requests while browsing the site and paying attention to sensitive functionalities. Keep track of every request sent during these actions.
  3. Use your creativity to think of ways to bypass access control or otherwise interfere with application logic.
  4. Think of ways to combine the vulnerability you’ve found with other vulnerabilities to maximize the potential impact of the flaw.
  5. Draft your report! Be sure to communicate to the receiver of the report how the issue could be exploited by malicious users.


  • You’ll need a detailed understanding of how your application works, how users interact with each other, how functionalities are carried out, and how complex processes work.
  • Carefully review each process for any logical flaws that might lead to a security issue. Conduct rigorous and routine testing against each functionality that is critical to the application’s security.
  • Avoid making implicit assumptions about user behavior or the behavior of other parts of the application
  • Maintain clear design documents and data flows for all transactions and workflows, noting any assumptions that are made at each stage.
  • Write code as clearly as possible. If it’s difficult to understand what is supposed to happen, it will be difficult to spot any logical flaws. Ideally, well-written code shouldn’t need documentation to understand it. In unavoidably complex cases, producing clear documentation is crucial to ensure that other developers and testers know what assumptions are being made and exactly what the expected behavior is.
  • Note any references to other code that uses each component. Think about any side-effects of these dependencies if a malicious party were to manipulate them in an unusual way.

You can follow me on twitter:



CS Student | Security Researcher ¯\_(ツ)_/¯

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store