The super-app authorization problem
A consumer fintech user has one role: consumer. A super-app user might be a consumer, a merchant, an agent, a field supervisor, or a combination of roles on the same account. The authorization system must correctly scope every API request to the permissions appropriate for the requesting user's current role context — not just their identity. When this scoping fails, a consumer account can reach merchant settlement APIs, an agent account can access admin functions, or a merchant account can query consumer wallet data that it has no business reading.
The complexity compounds because super-apps grow by acquisition and by fast shipping. A new lending product is added to the platform by integrating a separate service that was built independently. That service's authorization model was designed for standalone use. When it is exposed through the super-app's API gateway, the assumption that all callers are verified lending applicants may no longer hold — the caller might be a consumer wallet session that should never have reached the lending service at all.
1. Cross-product authorization testing
We systematically test whether a session token issued for one product can reach endpoints belonging to other products. The methodology: authenticate as a consumer wallet user, extract the session token, then use that token to call merchant dashboard endpoints, agent management endpoints, and lending product APIs. For each endpoint, we record whether the response is: a 401 (no auth), a 403 (auth but no permission — correct), or a 200 with data (cross-product access succeeded — critical finding).
2. Agent account privilege and shared credential risks
Agent accounts on Nigerian super-app networks often have larger transaction limits, the ability to accept large cash deposits, and access to settlement data for the agent's own customers. We test agent account authorization boundaries: can an agent account access settlement data for customers of a different agent in the same network? Can an agent account initiate transactions above the agent's approved tier? Can an agent account be elevated to agent supervisor through an API role manipulation?
We also assess the agent credential management model. Physical agent locations are high-risk credential environments: devices are shared, PINs are known to multiple people, and device theft is a real operational risk. We test whether agent account sessions expire after inactivity, whether a session can be remotely terminated by the agent manager, and whether a compromised agent device can be blocked without disrupting the agent's legitimate operations.
3. Wallet-to-lending product bridge exploitation
Super-apps that offer both a wallet and a lending product create a bridge: users can receive a loan disbursement into their wallet and use it immediately. We test the security of this bridge specifically. Can a user claim a loan disbursement before their loan has been approved? Can the disbursement destination be changed from the user's own wallet to an external account through a parameter manipulation in the disbursement API? Can the wallet balance check that gates lending eligibility be manipulated to qualify for a larger loan than the actual wallet history justifies?
4. Merchant settlement fraud via account manipulation
Super-app merchants accept payments from consumers and receive settlement into a linked bank account. We test the merchant account management flow for: the ability to change the settlement bank account without step-up authentication, the ability to modify merchant profile information (business name, category) that affects transaction limits and reporting, and the ability for a consumer session to access a merchant account associated with the same phone number without explicitly switching to the merchant role.
5. Multi-role same-account session handling
Many super-app users are both consumers and merchants on the same phone number. The platform must correctly switch between the consumer and merchant contexts when the user switches roles in the app. We test whether the role switch is enforced at the API level or only at the UI level. If switching from consumer to merchant mode in the app simply sends a different header or parameter in subsequent requests — without the backend issuing a new, appropriately scoped session token — an attacker can impersonate the role switch by manually setting the header on any request.
Consumer session token accepted on merchant settlement endpoint
During a penetration test of a Nigerian super-app platform, we authenticated as a consumer wallet user and used our session token to call the merchant settlement history endpoint — an endpoint intended for merchants to view their daily settlement records. The endpoint validated that the session was authentic but did not check that the session belonged to a merchant account. We received the settlement records for a merchant account that shared our test phone number. By iterating through merchant IDs in the request, we accessed settlement data for merchants we had no relationship with. Fix priority: critical. Remediated by implementing role-scoped session tokens: when a user switches to merchant mode, a new session token is issued with explicit merchant scope. The merchant settlement endpoint rejects any token that does not carry merchant scope, regardless of who the authenticated user is.
Operating a Nigerian super-app or multi-product fintech platform? Book a security assessment that covers the full cross-product authorization surface.
Book a Super-App Security AssessmentFrequently asked questions
What makes a super-app harder to secure than a single-product fintech?
A single-product fintech has one data model, one authorization system, and one user role hierarchy. A super-app combines multiple products — wallet, POS, lending, agent banking, merchant acquiring — each built by different teams at different times, each with its own data model and authorization logic. The attack surface grows with each product, and the boundaries between products create cross-product authorization risks that do not exist in single-product platforms. An attacker who has a merchant account on OPay can test whether that merchant session allows access to wallet or lending endpoints that it should not reach.
Why are agent networks a specific security concern for super-apps?
Super-app agents — the network of third-party individuals who provide cash-in, cash-out, and POS services — have elevated access rights relative to regular users. An agent account can accept deposits, initiate large transfers, and in some platforms access merchant settlement data. Agent accounts are also shared between multiple people at a physical agent location, which means credential theft at a single agent point affects the entire agent's operational scope. Agent account compromise is one of the highest-risk scenarios in super-app security.
How does cross-product authorization failure work in a super-app?
If a user's session token grants access to resources across all of the super-app's products rather than being scoped to the product the user is using, an attacker with a valid consumer wallet session can attempt to access merchant API endpoints, agent management endpoints, or lending product APIs that they are not meant to reach. If the authorization check on those endpoints validates only that the requester is an authenticated user of the platform — not that they have the specific merchant or agent role required — the session crosses the product boundary it should not cross.
Related reading
Blog: Neobank penetration testing · Business banking security audit · BOLA in financial APIs
Services: Penetration testing · API security