A service that limits only login attempts can still be abused through account creation, recovery, token generation or a high-volume administrative operation. Effective limits follow how the product is used and how it could be misused.
Apply limits at multiple scopes
User-level limits control how much activity one identity can generate. Session-level aggregation prevents the same user bypassing a limit by opening more sessions. Tenant-level limits help prevent one customer’s activity from degrading service for other tenants.
IP-level limits add a network signal but should account for shared proxies and distributed traffic. Operation-level limits can target sensitive actions such as account creation and recovery. WebFrolic documents configurable limits across these five scopes, with user-level flexibility for legitimate high-volume identities.
Tune policy to behaviour and risk
A generous limit may not slow abuse; a strict one can lock out legitimate users behind a corporate proxy or disrupt a service workload. Start with observed traffic, identify normal bursts and choose limits that leave room for legitimate peaks while making repeated abuse expensive.
Different operations deserve different thresholds. Account recovery may need stricter control than a read-only profile call. A service identity may need a higher quota than an ordinary user, but the exception should be tied to its purpose and monitored.
Make limits useful during incidents
Rate limits can slow a compromised privileged identity’s ability to make large changes, giving defenders a chance to respond. They are not a complete containment plan: alerting, investigation and a way to restrict the compromised identity are still needed.
Use telemetry for limit hits, affected principal, tenant, operation and time window. Be cautious about logging sensitive request values. Alert on patterns that suggest distributed abuse, such as repeated denials across many IPs or coordinated attempts against many accounts.
Test thresholds with realistic traffic
Load testing should include normal peaks, retries, shared-network users, service workloads and attacks distributed across sessions or IPs. Validate that user-level limits cannot be bypassed by opening more sessions and that tenant controls behave as intended.
Review limits after product changes. A new workflow may create a new abuse surface or change request distribution. Treat the policy as an operational control with an owner and review history, not a one-time setting.
The short version
Define user, session, tenant, IP and operation scopes. Then: define user, session, tenant, IP and operation scopes; measure normal bursts before setting thresholds; ensure limit telemetry supports incident response.