The API data leak problem in Nigerian fintechs
Here is a scenario we encounter in nearly every Nigerian fintech engagement: the mobile app displays a user's first name and wallet balance. That is all the customer sees. But behind that clean interface, the API endpoint returning that data also sends back the user's full BVN, date of birth, residential address, NIN, linked bank account numbers, and internal database identifiers - all serialized into the response payload. The frontend developer simply chose not to display those fields. The data is still there in every response, visible to anyone who opens their browser's developer tools or runs a proxy like Postman.
This is not a theoretical concern. During our penetration testing engagements, we routinely find Nigerian fintech APIs that expose between 5 and 15 unnecessary data fields per response. In one engagement, a single user profile endpoint returned BVN, NIN, mother's maiden name, and the hashed (but not salted) password - none of which the frontend displayed. Under the NDPA, exposing personal data through an API - even if the frontend does not render it - constitutes a data processing violation. Penalties reach up to ₦10 million or 2% of annual gross revenue.
The five tests below will help you identify the most common and most dangerous API data leaks. You do not need specialized security tools. A browser, your application's API documentation (or the network tab in your browser's developer tools), and a tool for sending HTTP requests are sufficient.
Test 1: the over-fetching test
Over-fetching is when your API returns more data than the client needs. This is the most common API data leak pattern because it is a development convenience - returning all fields from a database query is easier than selecting specific columns. But every extra field in the response is a data point an attacker can harvest.
How to run this test
Step 1: Open your application in a browser and navigate to your user profile page, account settings, or any page that displays user information.
Step 2: Open the browser's developer tools (F12 or right-click and select "Inspect"). Go to the Network tab and filter by "XHR" or "Fetch" to see only API calls.
Step 3: Reload the page. You will see the API requests that power the page. Click on the request that returns user data (typically a GET request to an endpoint like /api/users/me or /api/v1/profile).
Step 4: Examine the response payload. Compare what the API returns against what the UI actually displays. Write down every field in the API response, then check each one against what is visible on the screen.
What to look for
Red flags include:
- BVN or NIN fields: Your profile page does not need to display these. If the API returns them, they are leaking to every client that makes the request.
- Internal database IDs: Fields like _id, user_id, or internal_reference that expose your database's primary key structure. These enable BOLA attacks by giving attackers a predictable pattern to enumerate other users' records.
- Email addresses or phone numbers of other users: In list endpoints (like transaction histories or contact lists), check whether the response includes personal data for counterparties that should be masked or omitted.
- Hashed or plaintext passwords: This should never appear in any API response under any circumstance.
- Creation timestamps or last login times: These can be used for targeted social engineering.
- Role or permission fields: Exposing a user's role (e.g., role: "admin") in the response tells attackers exactly which accounts have elevated privileges.
What it means if you find it
Your API is returning data that should never leave the server. This is a data minimization violation under the NDPA and a direct security vulnerability. The fix is to implement explicit response serialization - use Data Transfer Objects (DTOs) or response schemas that whitelist exactly which fields are included in each API response, rather than returning entire database objects. For detailed implementation guidance, see our guide on securing fintech APIs.
Test 2: the BOLA / IDOR test
Broken Object-Level Authorization (BOLA) - historically known as Insecure Direct Object Reference (IDOR) - is the number one API vulnerability on the OWASP API Security Top 10 and the single most common critical finding in our Nigerian fintech engagements. It allows an authenticated user to access another user's data by simply changing an ID parameter in the API request.
How to run this test
Step 1: Log into your application and navigate to your profile page or any page that displays your personal data.
Step 2: In your browser's developer tools (Network tab), find the API request that retrieves your profile. Note the URL structure. It will typically include your user ID - something like /api/users/12345 or /api/v1/accounts/abc-def-ghi.
Step 3: Copy that request URL. Using a tool like Postman, Insomnia, or even your browser's console, make the same request but change the user ID to a different value. If your ID is 12345, try 12344, 12346, or any other value. Keep your same authentication token - you are testing whether the server verifies that you are authorized to view someone else's record, not just whether you are authenticated.
Step 4: Check the response. If the API returns another user's data, you have confirmed a BOLA vulnerability.
What it means if you find it
This is a critical severity finding. It means that any authenticated user on your platform can access any other user's data - their profile, transactions, wallet balance, KYC documents - by simply iterating through ID values. An attacker could write a simple script that increments the user ID and downloads your entire customer database, one record at a time.
The fix is to implement server-side authorization checks on every API request. The server must verify that the authenticated user is authorized to access the specific resource being requested - not just that they have a valid session token. For a comprehensive walkthrough of this vulnerability and its remediation, read our dedicated article on fixing broken object-level authorization.
Found a BOLA vulnerability in your API? That is the tip of the iceberg. Let our team assess the full scope.
Get an API Security AssessmentTest 3: the rate limiting test
Rate limiting controls how many requests a client can make to your API within a given time window. Without it, attackers can perform credential stuffing (thousands of login attempts per minute), brute-force OTP codes, enumerate user accounts, and scrape your entire database through legitimate-looking API calls.
How to run this test
Step 1: Choose a sensitive endpoint. Your login endpoint, password reset endpoint, OTP verification endpoint, or user search endpoint are the highest-risk targets.
Step 2: Using Postman's Collection Runner, a simple script, or even rapid manual requests, send 100 identical requests to that endpoint within 10 seconds. Use deliberately wrong credentials (do not lock out your own account).
Step 3: Check the responses. After your first few requests, the server should start returning HTTP 429 (Too Many Requests) responses. Check the response headers for rate limit information - headers like X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After.
What it means if you find no rate limiting
If all 100 requests succeed with HTTP 200 responses, your API has no rate limiting on that endpoint. This means an attacker can:
- Credential stuff your login endpoint: Try millions of username-password combinations from leaked databases until they find valid credentials.
- Brute-force OTP codes: A 6-digit OTP has only 1 million possible combinations. Without rate limiting, an attacker can try all of them in under an hour.
- Enumerate user accounts: Systematically try email addresses or phone numbers against your registration or password reset endpoint to determine which ones are registered on your platform.
- Scrape customer data: If combined with a BOLA vulnerability, the attacker can iterate through every user ID in your database without any throttling.
For detailed implementation guidance on rate limiting patterns specific to payment APIs, read our technical guide on rate limiting and anti-fraud controls for payment APIs.
Test 4: the error message test
Error messages are one of the most overlooked sources of data leakage in APIs. When your API encounters an error, the information it returns in the error response can reveal your tech stack, database structure, internal file paths, and even source code snippets to an attacker.
How to run this test
Step 1: Send malformed requests to your API endpoints. Remove required fields, send invalid data types (a string where a number is expected), use extremely long input values, or include special characters like single quotes, angle brackets, and semicolons in text fields.
Step 2: Examine the error responses carefully. You are looking for information that should never be exposed to external clients.
What to look for
Stack traces
Full error stack traces that reveal your programming language, framework version, file paths, and line numbers. A stack trace showing "/app/src/controllers/UserController.js:47" tells an attacker your exact code structure.
Database table names
Error messages like "column 'bvn_number' does not exist in table 'user_profiles'" reveal your database schema, making SQL injection attacks dramatically easier to craft.
Internal IP addresses
Error messages that reference internal infrastructure like "Connection refused to 10.0.3.47:5432" reveal your internal network topology and database server locations.
Third-party API keys
Error responses that include upstream service error details, like a failed Paystack or Flutterwave API call that includes your merchant secret key or API key in the error context.
What it means if you find it
Verbose error messages give attackers a detailed map of your internal architecture. They reduce the time and effort required to find and exploit vulnerabilities. The fix is straightforward: implement a global error handler that returns generic error messages to clients (like "An error occurred. Please try again.") while logging the detailed error information server-side. Never expose stack traces, database details, or internal infrastructure information in production API responses. Your .env file configuration should ensure debug mode is disabled in production.
Test 5: the token expiry test
When a user logs out of your application, their session should be completely invalidated. If an old JWT or session token still works after logout, it means an attacker who intercepts that token - via network sniffing, XSS, or device theft - can use it indefinitely to access the user's account.
How to run this test
Step 1: Log into your application. Open the developer tools and locate your session token. For JWT-based authentication, it is typically stored in localStorage, sessionStorage, or a cookie. Copy the full token value.
Step 2: Use the token to make a successful API request (like fetching your profile). Confirm the request works and returns your data.
Step 3: Log out of the application through the normal UI flow.
Step 4: Immediately use the copied token to make the same API request again. You can do this by pasting the token into the Authorization header in Postman or your browser's console.
Step 5: Check the response. If the API returns your data, the logout did not actually invalidate the token.
Additional checks
- Token lifetime: If you are using JWTs, decode the token (using jwt.io or a similar tool) and check the expiration claim (exp). JWTs for fintech applications should expire within 15 to 30 minutes. If your token's expiry is set to 24 hours, 7 days, or "never," that is a critical finding.
- Refresh token rotation: If your application uses refresh tokens, check whether each refresh token can only be used once. Use a refresh token, get a new access token, then try to use the same refresh token again. If it works a second time, your refresh tokens are not being rotated - meaning a stolen refresh token grants indefinite access.
- Concurrent sessions: Log into the same account from two different browsers simultaneously. Both sessions should work. Now change the password from one browser. Go to the other browser and try to make an API request. If the old session still works after a password change, your session invalidation is broken.
For a comprehensive analysis of JWT security pitfalls specific to fintech applications, read our article on JWT token security mistakes.
What it means if you find it
Failed token invalidation means that stolen tokens remain valid long after the user believes they have logged out. In the Nigerian context - where shared devices are common, public Wi-Fi usage is high, and mobile device theft is a real risk - this vulnerability directly enables account takeover. The fix involves implementing server-side token blacklisting or using short-lived tokens with a secure refresh token rotation mechanism.
These 5 tests cover roughly 10% of a real API pentest
The five tests above target the most visible and most commonly exploited API vulnerabilities. But a comprehensive API security assessment also covers authentication bypass techniques, injection attacks (SQL, NoSQL, command injection), business logic flaws like race conditions in financial endpoints, webhook security validation, file upload abuse, server-side request forgery (SSRF), and dozens of additional attack vectors. If these five basic tests revealed issues, the remaining 90% of your API's attack surface almost certainly contains more - and likely worse - vulnerabilities.
What a full API pentest covers that these tests do not
The gap between these five self-service tests and a professional API penetration test is substantial. Here is what you are missing:
Business logic testing
Race conditions in payment APIs, double-spend vulnerabilities, float manipulation, and transaction sequencing attacks. These require understanding your specific payment flows and cannot be detected by generic testing. See our analysis of business logic flaws in payment platforms.
Authentication bypass
JWT algorithm confusion attacks, token forgery, OAuth misconfiguration, and password reset flow manipulation. Automated scanners do not test these - they require manual analysis of your specific auth implementation.
Injection attacks
SQL injection, NoSQL injection, OS command injection, and LDAP injection across every input parameter in your API. Professional testers use context-aware payloads tailored to your specific tech stack and database.
Webhook and callback security
Replay attacks against payment webhooks, signature validation bypass, and SSRF through callback URL manipulation. Read our webhook security guide for context on why this matters for payment platforms.
A focused API penetration test for a Nigerian fintech typically takes 5 to 10 business days and costs between $5,000 and $15,000 depending on scope. For transparent pricing details, see our penetration testing pricing guide. For a walkthrough of the engagement process, read how a Simpa Labs pentest works.
Ready to go beyond the basics and get a professional assessment of your API's security?
Book an API Security AssessmentFrequently asked questions
Can I test my API for vulnerabilities without being a security expert?
Yes. The five tests in this article require no specialized security tools - just a browser's developer console, your API documentation, and a tool for sending HTTP requests (like Postman or Insomnia). These tests check for the most common and most dangerous API vulnerabilities: data over-exposure, broken access controls, missing rate limits, information disclosure in errors, and session management failures.
What is the most common API vulnerability in Nigerian fintech applications?
Broken Object-Level Authorization (BOLA) - also known as Insecure Direct Object Reference (IDOR) - is consistently the number one API vulnerability we find in Nigerian fintech applications. It allows an authenticated user to access another user's data simply by changing an ID parameter in the API request. It is devastatingly simple to exploit and disproportionately common in applications that grew rapidly without security review.
How much of my API's attack surface do these 5 tests cover?
These five tests cover approximately 10-15% of a comprehensive API penetration test. They address the most visible and most commonly exploited vulnerabilities. A full API pentest also covers authentication bypass, injection attacks, business logic flaws, race conditions, webhook security, file upload abuse, GraphQL-specific vulnerabilities, and dozens of other attack vectors that require specialized tooling and methodology.
How often should I test my API for security vulnerabilities?
At minimum, after every major release that changes authentication, authorization, or payment logic. The CBN's Risk-Based Cybersecurity Framework requires annual penetration testing for licensed financial institutions. Best practice for active fintech platforms is quarterly testing, with continuous automated scanning supplementing manual reviews. Every new API endpoint should undergo security review before deployment to production.
Related reading
Blog: BOLA: the most dangerous API vulnerability · JWT token security mistakes · Rate limiting for payment APIs · Securing fintech APIs in Nigeria
Guides: OWASP for fintechs · Web application pentesting in Nigeria · Penetration testing pricing
Services: API security · Penetration testing · Payment gateway security