Business Logic Flaw That Bypassed Approvals

When people think about web application security, they usually focus on authentication, authorization, and access control. However, some of the most dangerous vulnerabilities come from something much simpler: broken business logic.

This real-world scenario shows how a payment platform failed to validate critical changes after approval, allowing an attacker to redirect funds and increase transfer amounts without triggering a new approval process.

---

Understanding the Payment Workflow 💳​

Imagine a payment processing company called Shinopay. The platform has three different user roles:
Admin
The Admin has full access to the platform and can approve any payment transfer.
Manager
The Manager reviews transfer requests and may receive delegated approval rights from the Admin. In this case, the Manager can approve transfers up to $10,000.
User
A regular employee who reviews documents and submits transfer requests for approval.

The intended workflow looks like this:

1. A User creates a transfer request.
2. The Manager reviews the request.
3. The Admin gives final approval.
4. Alternatively, the Admin can delegate approval rights to the Manager for transfers under a specific limit.

There is one critical security rule:
⚠️ If any approved transfer is modified, it must return to the approval queue and require approval again.
This rule exists to prevent unauthorized changes after approval.

---

The Security Research Begins 🔍​

The security researcher spent time understanding how the platform handled permissions, approvals, and delegated authority.
While analyzing the application, they discovered that the backend was using GraphQL.
After testing several GraphQL queries, they found information related to delegated approvals and identified a delegation record used by the system.

{
  "delegation_id": "del-001"
}

This delegation ID was used whenever a Manager approved transfers using Admin-granted authority.

---

Creating a Transfer Request 💰​

The researcher created a normal transfer request.

POST /api/v1/transfers
Authorization: Bearer TOKEN

{
  "amount": 50.00,
  "currency": "USD",
  "beneficiary_id": "company-id",
  "description": "Office supplies quarterly payment"
}

The transfer amount was only $50, making it appear harmless.

---

Analyzing the Approval Process​

First, the researcher observed a Manager approving a transfer without delegated permissions.

POST /api/v1/transfers/txn-231/approve
Authorization: Bearer TOKEN

{}

Next, they repeated the process after granting delegation rights to the Manager.

POST /api/v1/transfers/txn-231/approve
Authorization: Bearer TOKEN

{
  "delegation_id": "del-001"
}

At this point, the server should verify several things:

✅ The delegation actually exists.​

✅ The Manager is authorized to use it.​

✅ The transfer amount stays below the approved limit.​

✅ The approval remains valid.​

Everything appeared to work correctly.
Or so it seemed.

---

Discovering a Hidden Endpoint ⚠️​

Before the money was transferred, the researcher discovered another API endpoint responsible for modifying transfer requests.

PATCH /api/v1/transfers/{transfer_id}/amend

According to the business rules, modifying an approved transfer should automatically:

• Remove the existing approval.
• Return the transfer to Pending status.
• Require a new approval cycle.

The web interface enforced this behavior.
However, the backend did not.
This is a classic example of trusting the client instead of enforcing security on the server.

---

Exploiting the Vulnerability 🚨​

Using an interception proxy such as Burp Suite, the researcher manually modified the approved transfer.

PATCH /api/v1/transfers/txn-231/amend
Authorization: Bearer USER_TOKEN

{
  "beneficiary_id": "attacker-company-id",
  "amount": 999999.00,
  "description": "Office supplies quarterly payment"
}

Two critical values were changed:

💸 The transfer amount increased from $50 to $999,999.​

🏦 The beneficiary was replaced with a company controlled by the attacker.​

Normally, this request should have been rejected immediately.
Instead, the server accepted it.

---

Why Did the Attack Work? 🤔​

The root cause was missing server-side validation.
After the original approval, the backend treated the transfer as permanently approved.
When the transfer was modified, the server failed to verify:

❌ Whether the amount had changed.​

❌ Whether the beneficiary had changed.​

❌ Whether the approval was still valid.​

❌ Whether a new approval process was required.​

As a result, the transfer retained its approved status despite being completely different from the transaction originally reviewed by management.

---

The Security Impact 🔥​

This vulnerability could allow an attacker to:

• Increase approved payment amounts.
• Redirect funds to unauthorized recipients.
• Bypass financial controls.
• Circumvent approval workflows.
• Potentially steal large amounts of money.

In financial systems, these types of vulnerabilities can be just as dangerous as remote code execution vulnerabilities.

---

Vulnerability Classification​

This issue falls into several well-known security categories:

• Business Logic Vulnerability
• Broken Access Control
• Missing Server-Side Validation
• Workflow Bypass
• Authorization Logic Flaw

These vulnerabilities are often difficult to detect because every individual API request appears legitimate.
The real problem lies in how the requests interact with the application's business process.

---

How Developers Can Prevent This Issue 🛡️​

Always Revalidate Modified Data​

Any change to a previously approved transaction should automatically invalidate the approval.

Never Trust Client-Side Restrictions​

Hiding a button in the user interface is not a security control.
Attackers can interact directly with backend APIs.

Recheck Authorization on Every Sensitive Action​

Every modification must trigger fresh authorization and approval checks.

Implement Audit Logging​

Record every approval, delegation, modification, and workflow transition.
This helps security teams investigate suspicious activity.

Test Business Logic During Security Reviews​

Many organizations focus on technical vulnerabilities while ignoring workflow abuse scenarios.
Business logic testing should be part of every penetration test.

---

Final Thoughts 🎯​

This case is a perfect example of why secure applications require more than authentication and role-based access control.
The platform had Managers, Admins, delegated permissions, and approval workflows. On paper, everything looked secure.
Yet a single flaw in the business process allowed an attacker to modify an already approved transaction, redirect funds, and dramatically increase the transfer amount without triggering a new review.
For developers, penetration testers, and security engineers, this serves as an important reminder:
If security rules exist only in the user interface and not on the server, attackers will eventually find a way around them.