Traditional rate limiting is usually applied as a request count per IP address. That model is simple, but NAT, carrier networks, shared egress points and anonymous gateways can put legitimate users and abuse sources in the same bucket. High traffic from a single IP is not always an attack; equally, distributed low-volume traffic is not always innocent.
Application behavior is not uniform. A short burst of asset requests during a page load is normal, but the same rate on a payment, login or API endpoint can signal abuse. A flat "N requests per minute" model can both harm user experience and miss genuine attacks.
Credential stuffing, account enumeration and bot patterns cannot be read from raw request counts alone. A large number of failed login attempts on an authentication endpoint may look low in total traffic. Counters that are not correlated with username, session, API key, custom header or response behavior lose their security context.
Resource protection is a separate concern. Even when distributed clients send requests at a low per-client rate, the aggregate load may exhaust a backend's connection pool, search infrastructure or file download capacity. Rate limiting is needed not only to stop an attacker, but to distribute backend capacity fairly and under control.
TR7's approach lifts rate limiting from a blunt IP-based threshold to a controlled security policy that can be applied across user, endpoint, session, API key, composite key and bandwidth dimensions.
TR7 implements rate limiting as a multi-dimensional WAAP control designed around scope, counter model and action selection working together.
TR7 tracks request, connection, error and bandwidth rates within a configurable time window. Different window lengths let short-duration spikes and sustained high load be evaluated independently.
Different scopes can be created using IP, IP and user agent, username, API key, cookie, header or composite keys. This allows abuse to be caught more precisely without penalizing legitimate users behind the same IP.
A policy can deny the request, apply a temporary block, redirect to CAPTCHA verification or impose a bandwidth cap. Not every violation is treated with the same level of response.
Counters are maintained inside the data path — no external database call is needed at decision time. Multi-instance deployments are supported through counter synchronization, enabling consistent policy enforcement across distributed setups.
TR7 Rate Limiting covers different abuse scenarios — from ready-made bot policies to custom composite keys — through a single management model.
TR7 ships with ready-made policies for common bot and abuse scenarios. The `bot_rateLimit` profile can return HTTP 429 at 300 requests per minute per IP. `bot_rateLimitStrict` can apply a 5-minute temporary block after 100 requests per minute. `bot_rateLimitCaptcha` can redirect to a self-hosted CAPTCHA flow after 150 requests per minute.
The `requests` type tracks raw request rate. `failedAuthAttempts` handles failed authentication attempts with a dedicated counter. `riskScore` can make decisions based on a bot or behavioral score. `static` is used for unconditional controls such as mandatory CAPTCHA on a specific flow.
The `global` scope monitors aggregate load across an entire service. `ip`, `ip+ua`, `username` and `composite` scopes create more targeted limits. The composite structure can combine a custom header, cookie, API key or a field from the request body to produce a custom counter key. This flexibility lets B2B API and multi-tenant applications reflect real usage limits more accurately.
A service pool can have multiple rate limiting policies active at the same time. For example, the same request can be subject to both an IP-scoped DDoS cap and a user-scoped fair-use limit. Each policy tracks its own independent counter. This structure enables a layered protection model instead of a single threshold.
When the `block` action fires, the affected key is held in the block table for the configured duration. This prevents an attacker from generating a short burst and then immediately returning after slowing down. The `blockDuration` is set per policy. This model provides stronger control against intense bot waves and repeat abuse sources.
The `captcha` action can redirect traffic that has exceeded the threshold or is flagged as risky to a verification flow rather than cutting it off entirely. The default provider is `tr7Standard`. On successful verification the user's request proceeds. This approach offers a more balanced alternative to blocking in scenarios where separating real users from automation is the priority.
TR7 can track inbound and outbound bandwidth rates in addition to request counts. With the `bwLimit` action, traffic matching a specific condition can be placed under its own bandwidth cap. This is useful for file download endpoints, endpoints that produce large responses, or high-volume data consumption from a single source — keeping the backend available without cutting it off entirely.
Information such as the username from an AAM session can be used as a rate limiting key. This allows a separate fair-use limit to be assigned to each user after login. Free and paid plans, internal and external user groups, or different role levels can each be governed by different limits. This provides more accurate control in API and portal scenarios where IP-based limits fall short.
For rate limiting policies to be effective, counter lifetime, table size, cluster synchronization, observability and rollback behavior must all be managed with operational clarity.
Different scopes operate with different table sizes. The global scope uses a single key while IP and composite scopes can hold a much larger number of entries. Long keys such as IP combined with user agent can consume more memory, so scope selection should be made against the expected traffic profile.
Counter synchronization across instances is supported in cluster deployments. Instances sharing the same policy key can discover each other and exchange counter state. This makes it harder for an attacker to bypass a limit by switching between instances in a load-distributed environment.
Stable table naming tied to policy identity helps preserve counter state across reload cycles. When the same policy continues under the same name, counters are not reset unnecessarily. This reduces the risk of a security gap opening during maintenance or configuration updates.
Rate limiting policies go through schema validation before being deployed. Invalid scope, trigger type or action definitions cannot enter the production configuration. This check reduces the risk of a misconfigured security rule disrupting live traffic.
Bot policy, account lockout rules and WAAP decisions can all run on the same request simultaneously. Priority order and match behavior are governed by configuration. Rate limiting therefore operates not in isolation but as part of the broader WAAP decision pipeline.
On each trigger, rule ID, action, key and rate information can be logged. These records can be forwarded to a SIEM for incident analysis and reporting. Operations teams can monitor the most frequently triggered keys, the busiest endpoints and blocking trends over time.
Organizations that offer B2B APIs can enforce a per-user plan limit and a per-IP abuse cap simultaneously. TR7 runs a user-scoped fair-use policy and an IP-scoped hard cap in parallel.
A high number of failed credential entries on an authentication screen can be a brute-force indicator. TR7 can track failures using a combined username and IP key and apply escalating actions — CAPTCHA first, then a temporary lock.
A short burst of requests on product pages may be normal, but the same pattern on a payment endpoint is a risk. TR7 can use endpoint conditions and different time windows to limit checkout abuse without degrading the page-load experience.
A single source can consume a backend's I/O capacity through high-volume downloads. TR7 uses the Bandwidth Limit Rule to cap that traffic conditionally, keeping the service available for other users.
Multi-layer rate policy across IP, user, API key and bandwidth dimensions. Let us walk you through a live setup on your own services.