1. Authentication & Session Management
Account takeovers (ATOs) drive the majority of direct financial losses in Nigerian fintech. Your auth perimeter must be airtight.
- OTP Rate Limiting: Implement strict rate limiting on OTP generation and validation endpoints to prevent brute forcing and SMS bombing.
- Recovery Flow Rigor: Password recovery mechanisms MUST invalidate all active sessions immediately upon initiation, and must not automatically log the user in without supplying the new password.
- Session Expiration: Enforce hard session timeouts (typically 15-30 minutes of inactivity) and ensure logout invalidates tokens on the server side, not just the client side.
- Concurrent Session Limits: Restrict the number of active devices per account. If a new device logs in, explicitly prompt for step-up authentication or invalidate older sessions.
- Device Fingerprinting: Tie active sessions to specific device IDs. If a session token is lifted and used on a new device, require re-authentication.
2. Payment & Transaction Logic
The core of your business. Scanners cannot find these flaws; they are purely logical vulnerabilities.
- Idempotency Keys: Every transaction endpoint MUST require and strictly validate a unique idempotency key to prevent double-spending or replay attacks during network timeouts.
- Decimal and Precision Handling: Ensure consistent rounding rules (e.g., banker's rounding) across the application, database, and third-party integrations to prevent fractional accumulation exploits.
- Negative Value Checks: Validate that transfer amounts, loan requests, and payment inputs cannot be negative, zero, or abnormally large.
- Race Condition Prevention: Use pessimistic locking (e.g.,
SELECT ... FOR UPDATE) on user balance records during withdrawal or transfer operations to prevent concurrent transaction exploits. - Webhook Signature Validation: Never trust a payment webhook purely based on its payload. Always validate the HMAC signature from providers like Paystack or Flutterwave before crediting an account.
Not sure if your idempotency logic is actually holding? Let engineers test it.
Get a Quick Security Check3. API Authorization (BOLA/IDOR)
Broken Object Level Authorization (BOLA) is the #1 vulnerability we find in modern APIs.
- Never Trust Client IDs: If a user requests a withdrawal, do not rely on a
userIdparameter in the JSON payload. Extract the user identity securely from the validated session token. - Resource Ownership Checks: Every API endpoint that accesses a specific resource (e.g.,
/api/cards/12345) MUST explicitly verify that the authenticated user actually owns resource12345. - UUIDs vs. Sequential IDs: Use UUIDv4 or KSUIDs for user IDs, transaction references, and account numbers to prevent enumeration tracking. Sequential IDs allow attackers to scrape your entire customer base.
4. Integrations & 3rd Parties
Nigerian fintechs rely heavily on external integrations (NIBSS, Smile Identity, Dojah, Mono). Security often fails at the seams.
- Default Deny on Upstream Failures: If a KYC provider or BVN endpoint times out or returns a 5xx error, default to denying the action. Never fail open.
- Callback URL Hardcoding: Ensure callback URLs submitted to payment gateways are strictly whitelisted on your server. Do not allow clients to dynamically specify return URLs in API requests.
- Third-Party Secret Rotation: Store all API keys in a secure vault (e.g., AWS Secrets Manager) and build processes to rapidly rotate them if a developer workstation is compromised.
The gap between theory and implementation
A client recently checked off "Idempotency Keys implemented." However, their implementation handled the idempotency check in application memory rather than the database. Under heavy load testing, we were still able to trigger a race condition that permitted double-spending. Passing a checklist is not the same as surviving an exploit.