Rate Limit Request

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 a request to a rate limit zone. This action does not perform any rate limiting checks.
• rate_limit.check_zone: Checks if the current request exceeds the rate limit for the defined zone. If the limit is exceeded, it applies the specified action (e.g., block, challenge, log).

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 ML fields: Results of machine learning based fingerprinting.

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.