API DDoS Protection: Layered Defenses That Hold

This guide shows you how to build a layered defense against Distributed Denial of Service (DDoS) attacks on your API. You’ll learn the specific controls to put in place at each layer—from the network edge to your application code—so that when one defense is overwhelmed, the next one catches the traffic. You’ll need administrative access to your DNS provider, your CDN or load balancer, and your API server configuration.

What You’ll Need

• A DNS provider that supports fast TTL changes and ideally DDoS mitigation.
• A CDN or reverse proxy (like Cloudflare, AWS Shield, or a self-hosted Nginx).
• Access to your API server’s configuration files and application code.
• Basic understanding of HTTP, rate limiting, and web application firewalls (WAF).

Step-by-Step

1. Start with network-level filtering. Configure your firewall or cloud security group to allow only necessary ports (usually 443 for HTTPS). Block ICMP (ping) floods by rate-limiting or disabling ICMP responses. Use a reputable DDoS protection service that can absorb volumetric attacks at the network edge—they have the bandwidth to handle massive traffic spikes that would saturate your own connection.
2. Put a CDN or reverse proxy in front. Route all API traffic through a CDN or a reverse proxy. This hides your origin server’s IP address, so attackers can’t target it directly. Ensure your origin only accepts traffic from the CDN’s IP ranges, not from the public internet.
3. Enable rate limiting at the proxy. Set rate limits per IP address, per API key, and per user. For example, allow 100 requests per minute per IP, and 1000 per hour per API key. Use a sliding window or token bucket algorithm to smooth out bursts. Start with generous limits and tighten them based on your normal traffic patterns.
4. Add a Web Application Firewall (WAF). Configure a WAF to block common attack patterns like SQL injection, cross-site scripting (XSS), and known bot signatures. Many WAFs also have DDoS-specific rules that can challenge suspicious requests with a JavaScript or CAPTCHA challenge. This stops many application-layer attacks before they hit your code.
5. Implement application-level rate limiting. Even with a proxy, your application should enforce its own limits. Use a library like express-rate-limit (Node.js), django-ratelimit (Python), or a Redis-backed rate limiter. This protects you if the proxy is bypassed or misconfigured.
6. Use caching aggressively. Cache responses for GET endpoints that are safe to cache. A CDN can serve cached responses without hitting your origin, reducing the load during an attack. Set appropriate Cache-Control headers and use short TTLs for dynamic data.
7. Set up anomaly detection and alerts. Monitor traffic for unusual spikes, high error rates, or a sudden increase in requests from a single IP range. Use your cloud provider’s monitoring tools or a third-party service to send alerts when thresholds are exceeded. The earlier you detect an attack, the faster you can respond.
8. Prepare an incident response plan. Write down the steps to take during an attack: who to contact, how to switch to a DDoS protection service, and how to scale up your infrastructure. Test the plan regularly with a tabletop exercise.
9. Consider a dedicated DDoS mitigation service. For high-risk APIs, use a service like AWS Shield Advanced, Cloudflare DDoS Protection, or a dedicated DDoS mitigation provider. These services offer always-on monitoring, automatic mitigation, and can handle multi-terabit attacks.
10. Keep your dependencies updated. Regularly update your web server, reverse proxy, and application frameworks. Vulnerabilities in these components can be exploited to amplify attacks or bypass your defenses.

Common Mistakes

• Relying on a single layer. A network firewall won’t stop an application-layer attack, and rate limiting won’t stop a 100 Gbps UDP flood. You need multiple layers.
• Rate limiting too aggressively. If your limits are too low, you’ll block legitimate users during a traffic spike. Always test with real traffic patterns.
• Exposing your origin IP. If your origin IP leaks (e.g., via DNS records, email headers, or a misconfigured server), attackers can bypass your CDN and hit it directly.
• Ignoring slowloris attacks. These attacks open many connections and send partial requests, tying up server resources. Use a reverse proxy that handles slow connections and sets timeouts.
• Not testing your defenses. You can’t be sure your layers work until you simulate an attack. Use tools like Apache Bench or specialized DDoS testing services (with permission) to see how your API behaves.

Tips

• Use a CDN that offers automatic DDoS mitigation—it’s often the easiest first line of defense.
• Set your DNS TTL to a low value (like 300 seconds) a few days before you expect an attack, so you can switch providers quickly.
• Implement authentication with API keys or OAuth, and reject requests without valid credentials early in the request lifecycle.
• Use HTTP/2 or HTTP/3 to reduce connection overhead, but be aware of their specific DDoS vectors.
• Monitor your API’s normal traffic baseline so you can spot anomalies quickly.

Troubleshooting

• Legitimate users are blocked. Increase rate limits, whitelist known good IPs, or use a CAPTCHA challenge instead of a hard block.
• Origin IP is exposed. Check DNS records for direct A records, review email headers, and search for your IP in public databases. Then restrict access to your origin to only your CDN’s IP ranges.
• Attack still gets through. Look at your WAF logs to see what rules are being triggered. If the attack is volumetric, you may need to upgrade your DDoS protection plan or enable “Under Attack” mode on your CDN.
• Performance degrades during an attack. Enable response compression, increase server resources, and ensure your database can handle the load. Consider using a read replica or a cache like Redis.
• Your API is slow even without an attack. Check for inefficient queries, missing indexes, or memory leaks. A well-optimized API is more resilient to DDoS.

Frequently Asked Questions

Can I protect my API from DDoS with just rate limiting?

No. Rate limiting helps with application-layer attacks, but it won’t stop a massive network-layer flood. You need network-level protection (like a DDoS mitigation service) to absorb volumetric traffic.

What is the difference between a SYN flood and an HTTP flood?

A SYN flood is a network-layer attack that exploits the TCP handshake, overwhelming the server with half-open connections. An HTTP flood is an application-layer attack that sends legitimate-looking HTTP requests, exhausting server resources.

Should I use a cloud-based DDoS protection service?

For most APIs, yes. Cloud-based services have the bandwidth and expertise to handle large attacks. They are cost-effective compared to building your own mitigation infrastructure.

How do I know if my API is under a DDoS attack?

Signs include a sudden spike in traffic, high CPU or memory usage, slow response times, and an increase in 5xx errors. Monitor these metrics and set up alerts.

Can a CDN completely hide my origin server?

If configured correctly, yes. You must ensure that no other services (like email or FTP) reveal your IP, and that your origin only accepts traffic from the CDN’s IP ranges.

What should I do if my API is under attack right now?

Immediately enable your DDoS protection service’s “Under Attack” mode, increase rate limits to block suspicious traffic, and contact your hosting provider for assistance. Do not try to fight the attack alone.

Related

• Roll to Defend Events Schedule: What It Is & How It Works
• Nginx Server Blocks on Debian VPS: Setup Guide
• Device Not Configured Correctly Code? Fix It Now