Table of Contents

Rate Limiter

The Rate Limiter allows you to protect your solution against excessive or malicious traffic by defining how many requests clients are allowed to make within a defined window of time. Requests are tracked per client IP address, and if limits are exceeded, users will receive an HTTP 429 Too Many Requests response.

Rate limiting is a cornerstone of defensive architecture and an important layer of defense against:

  • Denial-of-Service (DoS / DDoS) attacks – overwhelming your infrastructure with requests
  • Brute force attacks – repeatedly attempting login requests
  • Abuse of resources – uncontrolled usage of endpoints such as image rendering or custom APIs

A typical use case is to set fair usage thresholds that protect your system, e.g.:

  • API endpoints: prevent abuse from integrations or bots
  • Ecommerce operations: protect checkout, cart, or search endpoints
  • Media services: throttle expensive rendering endpoints
  • Backoffice tools: prevent accidental flooding from integrations or misconfigured jobs

By configuring policies at both system and custom levels, you can strike the right balance between protection and usability.

To enable rate limiting:

  1. Go to Settings > System > Web & HTTP > Rate Limiter > General
  2. Check Enable Rate Limiter
  3. Save
Tip

How it works

The Rate Limiter is built on top of the official ASP.NET Core rate limiting middleware and extends it with first-class configuration and policy management inside DynamicWeb.

Once enabled, DynamicWeb injects middleware (UseConfiguredRateLimiter) into the ASP.NET Core pipeline. This middleware decides, per request, which policy should apply and whether to enforce a global fallback:

  1. A request arrives
  2. Requests are grouped by client IP (X-Forwarded-For / X-Real-IP supported). This ensures limits apply per individual client
  3. DynamicWeb checks if a specific policy applies (system or custom)
  4. If none matches, the global policy is applied
  5. If a request is rejected, the middleware logs the attempt (with throttled logging to avoid flooding) and responds with HTTP 429 and a Retry-After header

It is not a substitute for firewalls or DDoS protection services, but it adds a strong, application-level safeguard that every high-traffic site should enable.

System policies

Policies are configured objects (RateLimiterPolicyConfiguration) that specify:

  • Permit limit: max requests allowed
  • Window: timeframe in seconds
  • Queue limit: number of excess requests to queue; if exceeded, requests are rejected immediately
  • Paths: which request paths the policy applies to
  • Priority: higher numbers take precedence if multiple policies match
  • Exclude from global limiter: isolates the policy from the global limit

DynamicWeb ships with three predefined system policies:

SystemPolicies

  1. Global (fallback):
    • 100 requests per 10 minutes
    • Applies broadly to frontend and /Admin/Public
    • Provides a baseline safety net for all traffic
  2. Authentication (login pages):
    • 10 requests per 60 seconds
    • Applies to /Admin/Authentication/Login, /ForgotPassword, /ResetPassword
    • Protects against brute force login attempts
    • Excluded from the global limiter, ensuring its stricter rules apply independently
  3. GetImage (image service):
    • 50 requests per 10 seconds, with a queue of 20
    • Protects expensive image rendering operations
    • Also excluded from the global limiter

System policies cannot be deleted but can be tuned (permit limit, window, queue limit).

Custom policies

You can create custom policies to protect any path or API in your solution:

  1. Go to Settings > System > Web & HTTP > Rate Limiter > Custom
  2. Click Add rate limiter policy.
  3. Configure:
    • Name
    • Permit limit
    • Window (seconds)
    • Queue limit
    • Paths (e.g. /api/myservice, /Admin/CustomTool)
  4. Advanced options:
    • Exclude from global limiter: Use this if the path should only be subject to this custom policy and not also throttled by the global fallback
    • Priority: Higher numbers ensure this policy overrides others when multiple match

Custom policies are persisted in the database (RateLimiterPolicies table) via the policy repository, cached for performance, and refreshed automatically.

Improve this doc
To top