Infosec Journey

If you’ve ever wondered whether rate limiting is a performance or security control, the answer is both. While I look at it from a security perspective, it’s also a powerful tool for maintaining system stability. Most modern products offer rate limiting out-of-the-box, making it an accessible layer of defense.

What Is Rate Limiting?

Rate limiting is primarily about restricting the number of requests a client can make. These requests are restricted to a service within a defined period. This simple idea has profound implications for both security and performance.

How Does Rate Limiting Fit into Security?

Rate limiting is more than just a way to control access. It’s about setting boundaries for how much your system can be accessed. It also defines who can access it and from where. To really understand its impact, you need to consider the OSI model. Rate limiting can be applied at different layers. Each layer has its own context and benefits.

Where Can Rate Limiting Be Applied?

Let’s look at the main controls and the layers they operate on:

• Web Application Firewall (WAF): Layer 7 (Application)
• Firewall (FW): Layer 3/4 (Network/Transport)
• Intrusion Prevention System (IPS): Layers 3–7 (depending on the product)
• Reverse Proxy: Layer 7 (Application)
• API Management/Gateway: Layer 7 (Application)
• Load Balancer: Layer 4/7 (Transport/Application, depending on features)

Real-World Scenarios and Technical Details

WAF: Protecting Against Credential Stuffing

Scenario:
A retail web app is targeted by automated bots attempting thousands of login attempts per minute.

Technical Implementation:
Configure a WAF with a rate limit rule:

• Threshold: 200 requests per minute
• Group by: Client address (each unique IP)
• Action: Block traffic exceeding the threshold

How it works:
If any single IP sends more than 200 requests to /login in one minute, further requests halt. No additional processing occurs. This blocks extra requests.

API Gateway: Preventing API Abuse

Scenario:
A SaaS provider exposes a public API. Some clients abuse the free tier by making excessive requests, impacting service for others.

Technical Implementation:
Set a rate limit rule in the API gateway:

• Threshold: 1000 requests per hour per API key
• Action: Reject requests exceeding the quota until the next hour

How it works:
Each API key is tracked individually. If a client exceeds its quota, further requests are rejected. This prevents resource exhaustion, ensures fair use, and thwarts API scraping or DoS attempts.

WAF (Geo-Based): Mitigating Regional DDoS

Scenario:
A news site experiences a spike in traffic from outside the US, likely due to a botnet attack.

Technical Implementation:
Set a geo-based rate limit rule:

• Threshold: 500 requests per minute per country (excluding US)
• Action: Block traffic exceeding the threshold

How it works:
If aggregate requests from any country (except US) exceed 500 per minute, further requests are halted. This applies specifically to that country. Monitoring ensures the requests are tracked each minute. Requests are monitored on a per-minute basis to ensure security. This mitigates DDoS attacks from specific regions and reduces risk from geo-targeted botnets.

Load Balancer: Thwarting SYN Floods

Scenario:
A gaming platform is targeted by a SYN flood (TCP connection flood) from a single IP.

Technical Implementation:
Configure the load balancer with a rate limit rule:

• Threshold: 50 new TCP connections per second per source IP
• Action: Drop or reset excess connection attempts

How it works:
If an IP attempts more than 50 new connections per second, further attempts are silently dropped. They are also reset. This protects backend servers from resource exhaustion and mitigates volumetric DDoS at the transport layer.

Firewall: Blocking ICMP Floods

Scenario:
A corporate firewall detects a volumetric ICMP (ping) flood from a single IP.

Technical Implementation:
Set an ICMP packet rate limit rule:

• Threshold: 10 pings per second per source IP
• Action: Drop excess packets

How it works:
If an IP exceeds 10 pings per second, further ICMP packets are dropped. This prevents network congestion and DDoS at the network layer.

How Major Platforms Handle Rate Limiting

Let’s go one step further and see how major platforms are handling rate limiting.

GitHub: IP-Based and Token-Based Rate Limiting

GitHub uses IP-based and token-based rate limiting for its REST APIs, with different limits for authenticated and unauthenticated users. If you make API calls to GitHub without authentication, you’ll quickly hit the 60-request-per-hour limit. Authenticating with a personal access token increases your limit to 5,000 requests per hour. If you exceed this, you receive a 403 Forbidden or 429 Too Many Requests response until the window resets. GitHub also provides response headers like X-RateLimit-Limit and X-RateLimit-Remaining so clients can monitor their usage.

LinkedIn: Application-Based and User-Based Rate Limits

LinkedIn uses application-based and user-based rate limits. Each app has a quota, for example, 500,000 requests per day. Each user can make a certain number of requests per app per day. If the limits are exceeded, LinkedIn throttles or blocks requests. All API requests must be authenticated, and rate limits are tied to both the app and user credentials.

Google Maps: Quota-Based and Cost-Based Rate Limiting

Google Maps APIs use quota-based and cost-based rate limiting. Each API key has a daily or per-minute quota (e.g., 1,000 requests per day for the free tier). Some APIs (like Directions or Places) have a “cost” per request which counts against your quota. Limits can also be enforced per API key and sometimes per IP. If you use Google Maps Directions API, each request might “cost” 10 units. If your daily quota is 1,000 units, you can make 100 requests before hitting your limit. If you exceed this, you’ll get an error until the quota resets.

By understanding and implementing rate limiting at the right layers and with the right strategies, you can significantly reduce risk and improve the stability of your systems.

Trends come and go, but security principles stay gold. Lock it down, stay ahead!