API rate limiting: why every app needs it and how to add it

Rate limiting is the control that says: this endpoint will respond to at most X requests per time window per source. It is the first thing an attacker probes for and the last thing most founders add. Here is why it matters and how to ship it quickly.

What breaks without it

Without rate limiting, your login endpoint accepts unlimited attempts. An attacker with a list of common passwords and a list of email addresses from a data breach can test every combination until something works. Your signup endpoint accepts unlimited registrations. A bot can spin up thousands of trial accounts. Your API endpoints accept unlimited requests. A competitor or scraper can download your entire product data model in minutes.

Each of these has a real cost: account takeovers, fraudulent trial abuse, infrastructure bills from unexpected traffic spikes, and data exposure. None require a sophisticated attacker.

Three tiers of rate limiting

Not all endpoints need the same limits. A useful mental model: authentication endpoints (login, signup, password reset, token refresh) are the highest risk and need the tightest limits. Mutation endpoints (anything that writes data, sends messages, or triggers external actions) are medium risk. Read endpoints are lowest risk but still need some floor to prevent scraping.

Adding it to a Node / Express app

The express-rate-limit package handles the common cases. Install it, configure a limiter, and apply it as middleware. For auth routes: 10 requests per 15 minutes per IP is a reasonable starting point. For general API routes: 100 per 15 minutes. Adjust based on what your legitimate users actually do.

For distributed apps or anything behind a load balancer, you need a shared store for the counts. express-rate-limit has a Redis store (rate-limit-redis) that wires in cleanly. Without it, each server process has its own count and a user can bypass the limit by hitting different instances.

Adding it at the edge with Cloudflare

If your app is behind Cloudflare, their Rate Limiting rules let you set per-path limits without touching application code. This is a fast option for adding limits to an existing app and has the advantage of dropping requests before they reach your servers at all.

Testing it

After adding rate limits, test them. Send enough requests to trigger the limit and verify the response is a 429 with a sensible Retry-After header. Verify the limit resets after the window expires. Verify that legitimate high-traffic users (mobile apps that poll frequently, webhooks from external services) are not caught by limits intended for human-rate behavior.

One afternoon, permanent improvement

Rate limiting is one of the highest-leverage security improvements for the time invested. A few hours of work closes a class of attacks that require no sophistication to execute. It belongs on every app before the first real user logs in.