Rate Limiting: The Quiet Feature That Prevents Most Abuse

Rate limiting rarely shows up in a project's initial feature list, and its absence is one of the more common gaps we find behind an actual abuse incident — a login endpoint that will happily accept ten thousand password guesses a minute, a contact form that becomes a spam cannon, an API that one misbehaving script can hammer into unresponsiveness.

What rate limiting actually prevents

• Brute-force login attempts — capping how many login attempts an account or IP can make in a given window, closing off a common path to the account takeovers two-factor authentication also guards against.
• Form and comment spam, by capping how many submissions a single source can make in a short period.
• Unintentional abuse from a misconfigured script or integration hammering an endpoint far more than any real usage would.
• A meaningful chunk of low-sophistication denial-of-service attempts, which rely on volume rather than any technical exploit.

Why it's easy to skip and expensive to skip

It doesn't show up in a demo, and it doesn't matter until the exact moment it does — usually during a spike of exactly the traffic it was meant to prevent. This puts it in the same category as the general security basics most projects underinvest in until an incident forces the issue.

Rate limiting is one of the few security measures that's almost entirely invisible to legitimate users and highly visible to abusive ones — there's very little tradeoff for getting it right.

We add sensible rate limits to every public-facing endpoint by default now, sized to normal usage patterns with headroom, rather than waiting for a specific incident to justify the work.