Distributed Denial Of Service in Chi with Api Keys

A DDoS attack targeting an API protected only by API keys can be especially effective when the keys are static, embedded in client code, or shared across many consumers. In Chi, rate limiting may be enforced at the gateway or application level, but if API keys are accepted without strict per-key quotas, an attacker who obtains a valid key can saturate backend resources quickly. Because API keys are often long-lived and rarely rotated, a compromised key provides a persistent channel for volumetric or application-layer floods that bypass IP-based defenses.

When API keys are passed in headers without additional context (for example, lacking a binding to a user identity or tenant), the service may process each request independently without correlating the load to a specific consumer. This allows an attacker to issue many concurrent requests that consume thread pools, database connections, or external downstream calls, leading to resource exhaustion. In Chi, if routes rely on synchronous processing or shared in-memory state without backpressure, a high request volume can cause request queuing, increased latency, and eventual timeouts for legitimate users.

Another angle is that API keys sometimes grant access to expensive operations such as searches, reports, or file generation. If these endpoints do not enforce per-key rate limits or cost-weighted quotas, a single compromised key can be abused to trigger computationally heavy work, amplifying the impact of a DDoS. Because middleBrick’s 12 security checks run in parallel, it flags missing rate controls and unauthenticated exposure as high-severity findings that contribute to the overall DDoS risk in the score. The scanner highlights these issues without assuming internal architecture, focusing instead on observable behavior such as missing rate limiting and excessive data exposure in error responses.

Implement per-key rate limits and ensure API keys are treated as credentials rather than secrets embedded in client-side code. In Chi, you can bind rate limiting to the key value extracted from headers and apply token-bucket or fixed-window algorithms to restrict requests per consumer. Below are concrete examples that demonstrate how to structure routes and middleware to reduce DDoS risk when using API keys.

Chi route with API key extraction and per-key rate limiting

open System
open Microsoft.AspNetCore.Http
open Microsoft.Extensions.DependencyInjection
open Microsoft.Extensions.Caching.Distributed
open System.Threading.Tasks

let rateLimitWindowSeconds = 60.0
let maxRequestsPerKey = 100.0

let apiKeyRateLimit (distributedCache: IDistributedCache) (next: HttpFunc -> HttpContext -> Task<HttpContext option>) : HttpFunc =
    fun (ctx: HttpContext) ->
        task {
            let! apiKeyOption =
                ctx.Request.Headers.TryGetValue("X-API-Key")
                ||> function
                    | true, [|key|] -> Some key
                    | _ -> None

            match apiKeyOption with
            | None ->
                return! next ctx
            | Some apiKey ->
                let cacheKey = $"rate_limit:{apiKey}"
                let! current = distributedCache.GetStringAsync(cacheKey) |> Async.AwaitTask
                let currentCount =
                    match Int32.TryParse current with
                    | true, n -> n
                    | _ -> 0
                if currentCount >= int maxRequestsPerKey then
                    ctx.Response.StatusCode <- StatusCodes.Status429TooManyRequests
                    return! Some ctx
                else
                    do! Async.AwaitTask (distributedCache.StringIncrementAsync(cacheKey))
                    |> Async.Ignore
                    do! Async.AwaitTask (distributedCache.ExpireStringAsync(cacheKey, TimeSpan.FromSeconds(rateLimitWindowSeconds)))
                    |> Async.Ignore
                    return! next ctx
        }

let app (builder: WebApplication) =
    let distributedCache = builder.Services.BuildServiceProvider().GetService<IDistributedCache>()
    builder.MapGet("/search", apiKeyRateLimit distributedCache (fun ctx next -> task {
        return! SearchHandlers.search ctx next
    }))
    |> ignore

Rotate keys and avoid embedding them in static bundles

Use environment variables or a secure vault to inject keys at runtime, and rotate them on a schedule. In client code, avoid committing keys to repositories. Example of safe configuration in appsettings.json (not committed):

{
  "ApiKeys": {
    "ServiceA": "%API_KEY_SERVICE_A%"
  }
}

In Program.cs or startup, bind keys without hardcoding them:

builder.Configuration["ApiKeys:ServiceA"] // read from environment or secret manager

Validate key format and scope before processing

Reject malformed or overly permissive keys early. For example, enforce a pattern and scope tags in the key metadata (if your key format supports it):

let isValidKeyFormat (key: string) =
    System.Text.RegularExpressions.Regex.IsMatch(key, "^[A-Za-z0-9\-_]{32,64}$")

let validateKeyScope (key: string) (requiredScope: string) =
    // If key includes encoded scopes, decode and check membership
    // This is illustrative; adapt to your key format
    key.Split('.')
    |> Array.contains requiredScope

Combine with other protections

Use middleware to reject requests with missing or invalid keys before they consume backend resources. Prefer short-lived keys for high-risk endpoints and monitor anomalies via logging and alerting. middleBrick’s GitHub Action can be added to CI/CD pipelines to fail builds if risk scores related to rate limiting and authentication drop below your chosen threshold, helping you catch regressions before deployment.