checkId: check.security.ratelimit plugin: stellaops.doctor.security severity: warn tags: [security, ratelimit, api]

Rate Limiting

What It Checks

Validates that rate limiting is configured to prevent API abuse. The check inspects the RateLimiting:* and Security:RateLimiting:* configuration sections:

ConditionResult
Enabled not set at allinfo — rate limiting configuration not found
Enabled is falsewarn — rate limiting explicitly disabled
PermitLimit > 10,000warn — permit count very high
WindowSeconds < 1warn — window too short
WindowSeconds > 3,600warn — window too long for burst prevention
Effective rate > 1,000 req/swarn — rate may be too permissive

The effective rate is calculated as PermitLimit / WindowSeconds.

Default values if not explicitly set: PermitLimit = 100, WindowSeconds = 60, QueueLimit = 0.

Evidence collected includes: enabled state, permit limit, window seconds, queue limit, and effective requests per second.

Why It Matters

Without rate limiting, the API is vulnerable to denial-of-service attacks, credential-stuffing, and resource exhaustion. A single client or compromised API key can overwhelm the service, affecting all users. Rate limiting is especially important for:

Common Causes

How to Fix

Docker Compose

Set rate limiting configuration:

environment:
  RateLimiting__Enabled: "true"
  RateLimiting__PermitLimit: "100"
  RateLimiting__WindowSeconds: "60"
  RateLimiting__QueueLimit: "10"

Bare Metal / systemd

Edit appsettings.json:

{
  "RateLimiting": {
    "Enabled": true,
    "PermitLimit": 100,
    "WindowSeconds": 60,
    "QueueLimit": 10
  }
}

Kubernetes / Helm

Set in Helm values:

rateLimiting:
  enabled: true
  permitLimit: 100
  windowSeconds: 60
  queueLimit: 10

For stricter per-endpoint limits, configure additional policies:

rateLimiting:
  policies:
    login:
      permitLimit: 10
      windowSeconds: 300
    scan:
      permitLimit: 20
      windowSeconds: 60

Verification

stella doctor run --check check.security.ratelimit