The evolution of API attacks in the Nigerian fintech sector
The days of attackers launching brute-force scripts from a single digital ocean droplet in Russia are over. Today's fraudsters are highly sophisticated. They utilize vast residential proxy networks to distribute their malicious requests across thousands of legitimate Nigerian IP addresses. To your web application firewall (WAF), this looks like organic, decentralized user traffic rather than a concentrated attack.
Because the Nigerian payment ecosystem relies heavily on mobile-first authentication (USSD, SMS OTPs, phone numbers as primary identifiers), the attack surface is distinctly different from Western markets. Your API architecture must be explicitly designed to handle these localized threat models.
Credential Stuffing
Using databases of passwords leaked from other global breaches, attackers automate millions of login attempts against your API, exploiting the fact that users habitually reuse their passwords.
Card Testing (BIN Attacks)
Attackers use your checkout endpoints to validate stolen credit card numbers by initiating high volumes of low-value (₦50) transactions, destroying your merchant reputation.
SMS Toll Fraud (IRSF)
Bots spam your "Send OTP" endpoint using premium-rate international phone numbers they control, draining your messaging budget (Twilio/Termii) overnight.
Advanced rate limiting patterns beyond the IP address
To stop highly distributed attacks, you must move beyond basic IP blocking and implement multi-dimensional rate limiting directly at the API Gateway or WAF level.
- Token-Bucket and Leaky-Bucket Algorithms: Stop relying on fixed-window counters. Use token-bucket algorithms that allow for sudden, legitimate bursts of traffic (like a user refreshing a page multiple times) while strictly enforcing a sustained limit over time.
- Entity-Based Limiting: Limit requests based on the specific entity being targeted, not just the source IP. For example, limit login attempts for a specific `username`, `phone_number`, or `account_number` to 5 per minute, regardless of how many thousands of different IP addresses the requests originate from.
- Device Fingerprinting: Integrate SDKs on the client-side that generate a unique device hash. Rate limit based on the `device_id` or `X-Device-Fingerprint` header. This catches attackers who rotate their IP address constantly but run their scripts from the same physical hardware.
- Endpoint-Specific Strictness: Not all endpoints are equal. Your `/api/v1/products` endpoint might allow 100 requests per second. Your `/api/v1/auth/login` endpoint should allow perhaps 5 per minute per user. Your `/api/v1/transfers/initiate` endpoint requires even stricter scrutiny.
Are your payment endpoints vulnerable to automated abuse and card testing?
Book an API Security AuditAnti-fraud logic in the application layer
Rate limiting at the gateway prevents your servers from crashing, but deep business logic is required in the application layer to stop the fraud itself. Gateway rules lack the contextual awareness of user behavior.
Velocity checks and behavioral profiling
You must monitor the velocity and behavioral context of transactions. If an account that typically transfers ₦10,000 a week to known beneficiaries suddenly attempts five ₦100,000 transfers in ten minutes to entirely new NIBSS destination accounts, the API should automatically halt the transactions. This should instantly trigger a manual fraud team review or require step-up authentication (e.g., forcing a biometric selfie verification before the transaction clears).
Defending the OTP endpoint
A standard 4-digit OTP has only 10,000 possible combinations. A 6-digit OTP has 1,000,000. These can be brute-forced in seconds by a moderately powered script if left unprotected. You must:
- Strictly limit submission attempts (e.g., lock the account or invalidate the token after exactly 3 failed attempts).
- Implement exponential backoff on the "Resend OTP" endpoint. The first retry might take 30 seconds, the next 2 minutes, the next 10 minutes. This prevents SMS toll fraud.
- Never return detailed error messages like "OTP is incorrect but only 2 attempts remaining." Return generic validation errors.
Webhook security and callback spoofing
When integrating with providers like Paystack or Flutterwave, your application relies on webhooks to confirm payment status. Attackers will attempt to discover your webhook listener URLs and send spoofed JSON payloads claiming a successful transaction. Your API must cryptographically verify the signature of every incoming webhook using the provider's secret key before updating a user's wallet balance. Never trust the IP address of the incoming request alone.
Testing your limits in the real world
During a comprehensive API security assessment, we actively attempt to bypass your rate limits using the exact methodologies employed by fraud syndicates. We utilize residential proxy rotation tools to test if your API correctly correlates attacks targeting the same account from disparate IP addresses. If our engineers can successfully brute-force an OTP, conduct SMS toll fraud, or enumerate valid phone numbers without triggering a hard block from your WAF or application logic, the rate limiting implementation has failed and must be redesigned.
Regulatory requirements for transaction monitoring
The Central Bank of Nigeria (CBN) strictly mandates robust anti-fraud and transaction monitoring capabilities for licensed entities. Failing to implement adequate rate limiting and velocity checks doesn't just result in financial loss; it exposes your organization to severe regulatory fines and the potential revocation of your operating license. Understanding these technical controls is fundamental to maintaining your compliance posture.
Related reading
Blog: Secure Your Fintech API · The Most Dangerous API Vulnerability · 10-point fintech security checklist
Services: API Security Testing · Secure Architecture Review · Authentication Security
Industries: Payment Gateways · Mobile Money
Frequently asked questions
Why isn't IP-based rate limiting enough to stop payment fraud?
Attackers route their requests through massive proxy networks and residential botnets, rotating their IP address with every single request. If you only limit by IP, they will easily bypass your controls because no single IP ever exceeds the threshold. You must implement entity-based limiting (by user ID, device ID, or card bin).
What is a card testing attack and how does it affect my payment gateway?
Fraudsters acquire stolen credit card databases and write automated scripts to attempt small transactions (e.g., ₦100) against your payment API. Their goal isn't to steal from you, but to determine which cards are still valid before using them for large purchases elsewhere. This spikes your chargeback rates and can cause NIBSS or Mastercard/Visa to revoke your processing privileges.
How does device fingerprinting stop distributed fraud?
Device fingerprinting allows you to identify when thousands of different user accounts are logging in or making transactions from the exact same physical device (e.g., matching browser canvas, fonts, OS hashes), indicating a coordinated attack rather than legitimate organic traffic.
What is SMS Toll Fraud (IRSF) and how do rate limits prevent it?
International Revenue Share Fraud (IRSF) occurs when attackers trigger thousands of OTP SMS messages to premium-rate international numbers they control, draining your Twilio or Termii balance in hours. Exponential backoff and strict hard limits on the 'resend OTP' endpoint prevent this.