The infrastructure multiplier problem
When you pentest a consumer fintech app and find a BOLA vulnerability, the impact is bounded by that app's user base. When you find a BOLA vulnerability in a BaaS provider that powers 50 downstream fintech applications, the impact is every user across all 50 platforms. Embedded finance platforms are high-value targets precisely because of this multiplier effect. Sophisticated attackers prioritize infrastructure over applications for exactly this reason.
The security responsibility is also split in ways that create gaps. The BaaS provider is responsible for their API security. The downstream fintech client is responsible for how they use that API. In practice, each party assumes the other has covered the gap — and neither tests the boundary between their responsibility and the provider's. Our engagements specifically scope the entire integration chain, not just one side of it.
1. Tenant isolation and cross-client data access
Multi-tenant BaaS platforms serve multiple client businesses through a shared backend. We test whether the tenant boundary is enforced at the data layer. The attack: authenticate as a legitimate client of the platform, then modify the tenant or client ID parameter in an API request to query data belonging to a different client organization. If the API returns data from the other tenant — transaction records, account details, customer PII — the tenant isolation has failed at the authorization layer.
We also test callback and webhook isolation. If Platform A and Platform B both receive webhooks from the same BaaS provider, we verify that events intended for Platform A cannot be delivered to Platform B's webhook endpoint through URL substitution or identifier manipulation.
2. Account data aggregator consent token security
Open banking aggregators like Mono and Okra use OAuth-style consent flows to obtain permission to read a user's bank account data. The consent token issued at the end of this flow is the most sensitive credential in the system — it grants read access to the user's complete transaction history across all linked bank accounts. We test:
- Token storage: Is the consent token stored encrypted at rest in the aggregator's database? If the database is compromised, can the tokens be used immediately?
- Token scope validation: Does the aggregator validate on each use that the token's scope matches the data being requested?
- Token revocation propagation: When a user revokes an aggregator connection in the bank's app, does the aggregator invalidate the token within the required timeframe?
- Downstream token handling: Does the fintech application that uses the aggregator API store the aggregator token or only use it server-side? Client-side token storage in mobile apps is a direct XSS or binary extraction risk.
3. API key management in BaaS integrations
BaaS integrations are authenticated with API keys issued to the downstream fintech client. We audit how these keys are managed: are they stored in environment variables or a secrets manager, are they rotated on a defined schedule, and are they scoped to only the operations the fintech client actually needs. We also test whether the BaaS provider's API key validation is rate-limited — a key brute-force attack that systematically tests key formats can enumerate valid keys if the validation endpoint does not throttle failed attempts.
4. Payment instruction injection in middleware APIs
Some embedded finance middleware platforms accept payment instructions from downstream clients and relay them to banking partners. We test whether the payment instruction validation at the middleware layer is strict enough to prevent a client from injecting malformed or unauthorized payment instructions. Specific tests include: submitting a payment instruction with a source account belonging to a different client, submitting a payment amount that exceeds the client's pre-approved transaction limit, and submitting a payment instruction with a modified settlement account that differs from the client's registered settlement account.
Cross-tenant data access via client ID substitution in aggregator API
During a security assessment of a Nigerian account data aggregator, we authenticated using our test client's API key and called the account data endpoint with the customer ID of a user we had enrolled during testing. We then modified the client ID header in the request to a different client ID that we had observed in a webhook payload. The API returned transaction data for a customer belonging to the second client — a different fintech company with completely separate users. The aggregator's authorization middleware validated the API key but did not validate that the client ID in the request matched the authenticated key's client. Fix priority: critical. Remediated by binding the client ID validation to the API key at the middleware layer, making it impossible to query another client's data with a valid but mismatched key.
Running an embedded finance platform, account aggregator, or BaaS middleware in Nigeria? Book an infrastructure security audit that covers the full integration chain.
Book an Embedded Finance AuditFrequently asked questions
Why is embedded finance infrastructure more critical to audit than a standard fintech app?
Embedded finance providers are infrastructure. A vulnerability in a BaaS middleware like OnePipe does not affect one company — it affects every business that has embedded financial services through that provider. A single exploitable endpoint in the aggregator layer can expose transaction data from hundreds of downstream clients simultaneously.
What is tenant isolation in embedded finance and how does it fail?
Tenant isolation means that data and operations for one client of a BaaS provider cannot be accessed or influenced by another client. Failure occurs when the API uses a shared database schema without row-level tenant filters, when webhook delivery does not validate that the receiving endpoint belongs to the correct tenant, or when API keys from one client can be used to query data belonging to another client.
How do account data aggregators like Mono create security risks?
Account data aggregators connect to banks on behalf of users to retrieve transaction history. The OAuth consent token that grants this access is highly sensitive. If the token is stored insecurely, transmitted without encryption, or not revoked when access is withdrawn, an aggregator breach exposes the complete transaction history and account balances of every connected user across every linked bank.
Related reading
Blog: Open banking aggregator security · Open banking API security Nigeria · BaaS virtual account exhaustion
Services: Penetration testing · Secure architecture review