The limitations of automated security
Many CTOs buy a subscription to an automated Dynamic Application Security Testing (DAST) tool and assume their APIs are secure. This is a fatal assumption.
DAST tools are excellent at finding technical misconfigurations (like Cross-Site Scripting or missing TLS). However, a DAST tool does not know that a user with a `Tier 1 KYC` status should be restricted to a ₦50,000 daily limit. When the tool sees the API accept a ₦500,000 transfer, it logs a `200 OK` success code and moves on. A human engineer sees that same `200 OK` and immediately recognizes a catastrophic compliance and financial breach.
Real-world business logic flaws
During our manual penetration tests of Nigerian payment gateways and lending apps, we consistently discover severe business logic vulnerabilities. Here are three common examples (anonymized):
1. The Race Condition (Float Duplication)
A mobile money agent has exactly ₦100,000 in their wallet. They use a script to send two concurrent `cash-out` API requests for ₦100,000 within the same millisecond. Because the database lacks strict row-level locking (mutexes), both threads read the balance as ₦100,000 before either thread deducts it. Both transfers succeed, leaving the agent with ₦200,000 in cash and the fintech with a ₦100,000 loss.
2. Partial Authorization Abuse
A user purchases a ₦20,000 item. During the checkout flow, they intercept the API request to the payment gateway and change the `amount` parameter from `20000` to `200`. The gateway processes the ₦200 charge successfully and returns a `status: success` webhook. The e-commerce backend only checks the `status` flag, not the authorized amount, and fulfills the ₦20,000 order.
3. Horizontal Privilege Escalation (IDOR)
A user logs into their loan dashboard. The API requests their profile data via `GET /api/user/v1/profile/9845`. The user manually alters the request in Burp Suite to `GET /api/user/v1/profile/9846`. Because the backend fails to verify if the requesting JWT token actually belongs to user `9846`, it returns the victim's full BVN, address, and loan history.
How to engineer secure business logic
Business logic flaws cannot be fixed by deploying a Web Application Firewall (WAF). They must be fixed in the application code itself.
Implement strict State Machines
Do not allow API endpoints to be called out of order. If a user is applying for a loan, they must pass through `Step 1: KYC`, `Step 2: Credit Check`, and `Step 3: Approval`. If an attacker attempts to call the `Step 3` API directly without a valid session token proving they completed Steps 1 and 2, the server must reject the request.
Enforce Server-Side Validation
Never trust the price, discount code, or fee calculations sent from the mobile app or web frontend. The client is in the hands of the enemy. The backend must recalculate every single financial value independently before processing the transaction.
Mandate Object-Level Authorization
It is not enough to verify that a user is logged in (Authentication). You must verify that the user is allowed to access the specific database row they are requesting (Authorization). Implement strict checks at the ORM/database layer to ensure `requesting_user_id == resource_owner_id`.
Is your payment platform vulnerable to race conditions or API manipulation?
Book a Manual PentestWhy manual testing is non-negotiable
To satisfy the CBN Cybersecurity Framework and truly secure your ledger, you must commission a penetration test that allocates the majority of its hours to manual business logic testing.
- Role-Based Access Control (RBAC) Audits: Engineers must be provided with multiple user accounts (e.g., Admin, Agent, User) to actively attempt privilege escalation.
- Concurrency Testing: Engineers must actively script multi-threaded attacks against your APIs to prove your database locks are functioning correctly under stress.
- Workflow Bypasses: Testers must attempt to manipulate multi-step flows, such as altering the destination account number *after* the OTP has been verified but *before* the transaction is committed.
Cheaper is often vastly more expensive
A fintech that relies solely on a ₦500,000 automated scan will eventually suffer a multi-million Naira loss due to a float duplication bug. Investing in premium, manual security engineering is significantly cheaper than funding an attacker's fraudulent cash-outs.
Frequently asked questions
What is a Business Logic Flaw?
A business logic flaw is a vulnerability that occurs when the application works exactly as coded, but the logic itself can be abused to bypass rules. For example, transferring a negative amount of money to increase your balance. Automated tools cannot detect these because they don't understand the context of the business.
Why do automated vulnerability scanners miss these flaws?
Scanners like Nessus or Acunetix look for known technical signatures, like outdated server software or missing HTTP headers. They cannot understand that 'User A should not be able to approve their own loan application' because that requires human context.
What is an Insecure Direct Object Reference (IDOR)?
IDOR happens when an application provides direct access to objects based on user-supplied input without properly checking authorization. If a user changes their API request from `GET /receipt/1001` to `GET /receipt/1002` and sees another user's receipt, that is an IDOR.
How does Simpa Labs test for business logic vulnerabilities?
We deploy highly skilled security engineers who manually map out the application's workflows. We use proxy tools like Burp Suite to intercept and modify API requests in real-time, attempting to bypass transaction limits, exploit race conditions, and escalate user privileges.
Related reading
Blog: How to Scope Your Pentest · Agent Banking Security
Guides: Fintech Security Checklist · Web App Pentest Guide
Services: Penetration Testing · API Security Testing