Rate Limit Request

The Rate Limit Request phase applies rate limiting to requests that have passed through previous phases. This phase controls the request rate from clients. If a client exceeds the allowed request rate for a defined zone, the system stops further processing of that request.

Actions

• rate_limit.add_zone: Adds the current request to a named rate limit zone's counter. This action is used to increment the count for a client, but it does not perform any checks or blocking itself. You must define what uniquely identifies a client using a key (e.g., IP address, header value).
• rate_limit.check_zone: Checks the current request against a named rate limit zone's counter. If the client's count exceeds the zone's configured threshold, the specified action (e.g., block, challenge, log) is triggered.

Both actions require a key to be defined to identify the client. For a full list of available key types, see the How to Configure Rate Limit Zones guide.

For a detailed guide on creating and using zones, see How to Configure Rate Limit Zones.

Example

starts_with(http.request.uri.path, "/api/")

This rule applies to all requests with a URI path starting with "/api/".

The configuration that applies in the action for this rule:

rate_limit.add_zone:
  zone: "api_requests"
  key:
    - type: "ip"
rate_limit.check_zone:
  zone: "api_requests"
  action:
    type: "block"
    status_code: 429

This configuration adds the request to the "api_requests" zone, using the client's IP as the key. It then checks if the request exceeds the rate limit for this zone, blocking it with a 429 status code if it does. For more information on these settings, refer to the Rate limiting section in the vconf documentation.

Flow between add_zone and check_zone

graph TD
    A[Incoming Request] --> B[rate_limit.add_zone]
    B --> C[rate_limit.check_zone]
    C -->|Within limit| D[Continue Processing]
    C -->|Limit exceeded| E[Apply Action]
    E --> F[Block/Challenge/Log]

Fields

The Rate Limit Request phase provides access to the following fields:

• Request fields: Request information such as host header, method, and IP source.
• GeoIP fields: Geolocation information such as AS number and country code.
• User agent fields: Client user agent information.
• Bot fields: Information about bot clients.
• Fingerprint fields: Client network fingerprint information.

Use Cases

1. Implement API rate limiting based on client IP.
2. Apply different rate limits for mobile and desktop users.
3. Set stricter rate limits for unverified bots.
4. Use machine learning fingerprints to detect and limit potential abuse.

Separate Phases for Rate Limiting

Peakhour.IO provides separate phases for rate limiting:

1. Rate Limit Request: Occurs early in the request processing pipeline.
2. Rate Limit Request Late: Occurs after the WAF phase.
3. Rate Limit Response: Occurs during the response phase.

These separate phases allow for:

1. Early filtering of high-volume attacks.
2. Application of rate limits based on WAF results.
3. Rate limiting based on response characteristics.

This multi-phase approach provides flexibility in implementing rate limiting strategies tailored to specific use cases and security requirements.