Rate Limiting and API Security: Why Every Public-Facing API Is a Liability Without Throttling

The API vulnerability that scales with success

A new SaaS product launches its API. Usage is low; no rate limiting has been implemented because the volume doesn’t warrant it. The product grows. Usage increases. At some point, a competitor’s automation starts scraping the API for competitive intelligence. A bad actor discovers the login endpoint and starts a credential stuffing attack, automated login attempts using known email/password combinations from previous data breaches. A well-intentioned client writes a synchronisation script that loops without a delay, hitting the API thousands of times per minute.

In each case, the API responds to every request. The server costs spike. The response time degrades for legitimate users. At sufficient volume, the service becomes unavailable entirely.

Rate limiting would have prevented all three scenarios. It was not implemented because the product team was focused on features, not infrastructure hardening.

OWASP’s API Security Top 10 lists “Unrestricted Resource Consumption” (formerly “Lack of Rate Limiting”) as a top-tier API security risk. The risk is not theoretical. The frequency with which production APIs lack basic throttling is documented across security research consistently, because rate limiting is the kind of infrastructure that gets planned but deferred until after an incident.

The technical implementation of rate limiting

Rate limiting operates at the request layer, identifying clients and tracking their request frequency. The implementation choices:

IP-based rate limiting, tracks requests per IP address. Effective against unsophisticated bots and scrapers. Insufficient for authenticated APIs where many legitimate users may share the same IP (corporate NAT, CDN edge nodes, shared mobile carrier IP pools).

API key-based rate limiting, tracks requests per API key, issued to authenticated clients. Allows different rate limits for different tiers (free tier: 100 requests/minute; paid tier: 1000 requests/minute; enterprise: negotiated limits). More precise than IP-based, appropriate for any API with authentication.

User account-based rate limiting, tracks requests per authenticated user account. Appropriate for user-facing APIs where user sessions are the correct identity boundary.

The rate limit response headers that allow clients to self-manage their request volume: X-RateLimit-Limit (the limit for the current window), X-RateLimit-Remaining (requests remaining in the current window), X-RateLimit-Reset (timestamp when the window resets). The Mozilla documentation on HTTP headers documents these header conventions. Providing these headers means well-behaved clients can reduce their request rate before hitting the limit, reducing the rate of 429 responses in normal operation.

The Cloudflare rate limiting layer for web applications

Cloudflare’s Rate Limiting product operates at the CDN layer, before requests reach the origin server. This provides two advantages over application-level rate limiting: it protects the origin server from the traffic volume even when the limit is exceeded (the request never reaches the application), and it applies to all requests including those targeting non-API paths (login forms, checkout endpoints, contact forms).

For web applications without a dedicated API gateway, Cloudflare rate limiting is the practical first line of defence. Rules can be configured to limit requests to specific URL patterns (/api/*, /login, /checkout) with separate limits for each. The rules are configured in the Cloudflare dashboard without changes to application code.

Application-level rate limiting (implemented in the application itself) provides more granular control and can be user-account aware, but requires code changes and doesn’t protect against requests that exhaust application resources before the rate limiting code executes.

The business cost of missing rate limits

The costs of an API without rate limiting materialise across multiple categories:

Infrastructure cost inflation, a scraping attack that generates 50x the normal request volume produces 50x the compute and bandwidth cost. Cloud infrastructure that auto-scales to meet demand scales cost alongside it. A sustained scraping attack can produce infrastructure bills in the thousands of euros before anyone notices.

Data leakage, a well-constructed scraping attack can extract a business’s entire product database, pricing structure, customer-facing content, or competitive positioning data. For e-commerce businesses, this means competitors can track pricing changes in real time and undercut immediately.

Service degradation, at sufficient request volume, even a simple rate-limiting bypass attack (where requests are distributed across many IPs to evade per-IP limits) can degrade response time for legitimate users. The web.dev performance standards for API response times become impossible to maintain under attack traffic.

Credential exposure, credential stuffing attacks against login endpoints use breached email/password combinations to test for account reuse. Without rate limiting on the login endpoint, a list of 10 million credentials can be tested within hours. With rate limiting, the same attack takes years.

The Webxtek Studio web app development service implements rate limiting as part of every API specification, not as an afterthought. The maintenance service includes API security auditing for existing web applications. The managed hosting service includes Cloudflare integration with rate limiting rules configured for common attack patterns.

For SaaS and technology businesses and e-commerce brands with public-facing APIs, rate limiting is not a feature. It is the minimum viable infrastructure for a production service. An API endpoint without throttling is not a technical detail, it is an open liability in production.