Limiting one IP is no longer enough to stop modern abuse.
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.
Our approach
TR7 implements rate limiting as a multi-dimensional WAAP control designed around scope, counter model and action selection working together.
Sliding-window model tracks real traffic behavior
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.
The limit key is chosen to match the attack class
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.
The action model is applied progressively based on severity
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.
In-process counter architecture keeps latency low
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.
Capabilities
TR7 Rate Limiting covers different abuse scenarios — from ready-made bot policies to custom composite keys — through a single management model.
Built-in rate limiting profiles provide a production-ready starting point
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.
A soft limit and a hard ceiling — the response is a climb, not a cliff
Every protection carries two thresholds. Crossing the soft limit triggers a measured response — delay, challenge, shape — and only the hard ceiling drops traffic. Monitor mode reports the two separately, so thresholds are set from what your own traffic actually did rather than from a number someone guessed. A single threshold forces the same choice every time: allow the attack through, or drop your customers with it.
Trigger types separate plain requests, failed logins and risk score
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.
IP, user and composite key scopes can be used together
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.
The same request can be evaluated against multiple rate policies simultaneously
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.
The temporary block action keeps the key blocked even after the rate drops
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.
Self-hosted CAPTCHA routes suspicious traffic to verification instead of a hard block
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.
The Bandwidth Limit Rule enables conditional traffic shaping
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.
AAM session variables enable per-user rate limiting
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.
Operational depth
For rate limiting policies to be effective, counter lifetime, table size, cluster synchronization, observability and rollback behavior must all be managed with operational clarity.
Adaptive counter table sizing
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.
Multi-instance synchronization
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.
Counter continuity across reloads
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.
Policy validation layer
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.
Action chain compatibility
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.
Audit and observability
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.
When to use it
Layered per-user and per-IP limits on an API gateway
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.
Failed attempt control on a login endpoint
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.
Per-endpoint protection in an e-commerce flow
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.
Bandwidth control on file download traffic
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.
Frequently asked questions
Does a per-IP rate limit affect real users behind NAT or shared egress?
What is the difference between the block action and the deny action?
How does the self-hosted CAPTCHA integration work?
Can more than one rate policy apply to the same endpoint?
Does the Bandwidth Limit Rule work differently from request counting?
Can different instances in a cluster share the same counter?
Shape rate limiting to the context of your application
Multi-layer rate policy across IP, user, API key and bandwidth dimensions. Let us walk you through a live setup on your own services.