security

Rate Limiting And Abuse Prevention

Rate limiting constrains repeated activity so one client cannot overwhelm a service or abuse sensitive actions. It complements authentication and validation; it does not replace them.

Core Controls

  • Rate-limit login, password reset, registration, expensive search, uploads, and public APIs.
  • Choose keys deliberately: IP address, account, token, route, or a combination.
  • Return a clear retry response without exposing internal thresholds unnecessarily.
  • Use shared counters when requests can reach several app servers.
  • Monitor blocked traffic and account for trusted proxies when reading client IPs.

Choose Keys Deliberately

An IP-only limit can punish many legitimate users behind one office network. An account-only limit lets an attacker distribute attempts across many accounts. Sensitive endpoints often need more than one counter.

PHP example
<?php

declare(strict_types=1);

function loginLimitKeys(string $email, string $ip): array
{
    $email = strtolower(trim($email));

    return [
        'login:ip:' . $ip,
        'login:account:' . hash('sha256', $email),
        'login:pair:' . hash('sha256', $email . '|' . $ip),
    ];
}

print_r(loginLimitKeys('Amo@example.com', '203.0.113.10'));

Hashing the email avoids placing the raw account identifier in cache keys or incidental diagnostics.

Use Shared Atomic Counters

Counters belong in shared storage such as Redis when requests can reach several PHP workers or servers. Increment and expiry operations must be coordinated so concurrent requests do not bypass the limit.

Edge limits at a CDN or gateway can absorb broad abuse. Application limits still matter when the rule depends on user identity, route semantics, or product behaviour.

Monitor The Result

Return 429 Too Many Requests with a retry hint where appropriate. Log enough information to investigate abuse without storing passwords, tokens, or unnecessary personal data. Monitor false positives as well as blocked attacks.

In Application Work

A fixed global limit is rarely enough. Login attempts need different limits from normal API reads, and attackers may distribute requests across IP addresses.

What To Check

Before moving on, make sure you can choose layered keys, explain shared atomic storage, return a useful retry response, and test normal-user, burst, and distributed-abuse scenarios.

Practice

Practice: Design Login Rate Limits

Requirements

  • Choose IP-based and account-based keys.
  • Define a time window and retry response.
  • Use shared storage across app servers.
  • Describe normal-user and attack scenarios.
Show solution

Review Points

  • Rate-limit login, password reset, registration, expensive search, uploads, and public APIs.
  • Choose keys deliberately: IP address, account, token, route, or a combination.
  • Return a clear retry response without exposing internal thresholds unnecessarily.
  • Use shared counters when requests can reach several app servers.
  • Monitor blocked traffic and account for trusted proxies when reading client IPs.