The evolution of API attacks
Fraudsters are sophisticated. They no longer launch attacks from a single server block in Russia. They use residential proxy networks to distribute their requests across thousands of legitimate Nigerian IP addresses, mimicking normal user traffic.
Credential Stuffing
Using databases of passwords leaked from other breaches, attackers automate login attempts against your API, hoping users reused their passwords.
Card Testing
Attackers use your checkout endpoints to validate stolen credit card numbers by initiating high volumes of low-value transactions.
OTP Brute-Forcing
Attackers attempt to guess the 4- or 6-digit OTP sent to a user's phone to authorize a transaction or password reset.
Advanced rate limiting patterns
To stop distributed attacks, you must move beyond basic IP blocking and implement multi-dimensional rate limiting at the API Gateway or WAF level.
- Token-Bucket Algorithms: Use algorithms that allow for sudden, legitimate bursts of traffic 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` or `account_number` to 5 per minute, regardless of how many different IPs are used.
- Device Fingerprinting: Integrate SDKs on the client-side that generate a unique device hash. Rate limit based on the `device_id` header to catch attackers rotating IPs but using the same hardware.
Are your payment endpoints vulnerable to automated abuse and card testing?
Book an API Security AuditAnti-fraud logic in the application layer
Rate limiting prevents the server from crashing, but business logic is required to stop the fraud itself.
Velocity checks
Monitor the velocity of transactions. If an account that typically transfers ₦10,000 a week suddenly attempts five ₦100,000 transfers in ten minutes, the API should automatically halt the transactions and trigger a manual review or require step-up authentication (e.g., a selfie verification).
Defending the OTP endpoint
A 4-digit OTP has only 10,000 possible combinations. It can be cracked in seconds if not protected. You must strictly limit attempts (e.g., lock the account after 3 failed attempts) and implement exponential backoff on the "Resend OTP" endpoint to prevent SMS toll fraud.
Testing your limits
During an API security assessment, we actively attempt to bypass rate limits. We use proxy rotation tools to test if the API correctly correlates attacks targeting the same account from disparate IP addresses. If we can successfully brute-force an OTP or enumerate valid phone numbers without triggering a block, the rate limiting implementation has failed.
Related reading
Blog: Secure Your Fintech API · The Most Dangerous API Vulnerability
Services: API Security Testing · Secure Architecture Review
Industries: Payment Gateways
Frequently asked questions
{faq.q}
{faq.a}