Cloudflare Rate Limiting & WAF: Denial of Wallet Schutz

Neue Bedrohung im Serverless-Zeitalter: Denial of Wallet (DoW)

In traditionellen On-Premise- oder virtuellen Serverumgebungen (EC2/Compute Engine) führt ein DDoS-Angriff (Distributed Denial of Service) dazu, dass die Server-CPU 100 % erreicht und der Dienst abstürzt. Dies wurde als Denial-of-Service-Angriff (DoS) bezeichnet.

In Pay-as-you-go-Serverless- und Edge-Computing-Umgebungen (AWS Lambda, Vercel, Supabase, Cloudflare Workers) sowie bei LLM-APIs (OpenAI, Anthropic Claude) führt ein DDoS-Angriff oder der wahllose Ansturm bösartiger Scraper-Bots jedoch nicht zum Dienstausfall, sondern zu einer riesigen Infrastruktur-Rechnungsexplosion.

Dies ist die fatalste Bedrohung moderner Cloud-Sicherheit: der Denial of Wallet (DoW)-Angriff.

[Denial of Wallet (DoW) Schadensfall (Stand 2026)]
- Entwickler veröffentlicht persönliches Projekt / Startup-API (Vercel + Supabase / Lambda + OpenAI API)
- Bösartiges Botnet erzeugt 100.000 API-Aufrufe pro Minute
- Ergebnis: Automatische Abrechnung von $5.000~$12.000 innerhalb eines Tages

Bisher wurde Rate Limiting (Traffic-Begrenzung) manuell implementiert, indem Anfragezähler in externem Redis (Upstash, Redis ElastiCache) oder Workers KV gespeichert wurden, um solche Dauerangriffe abzuwehren.

Dieser Ansatz wies jedoch klare Grenzen auf: (1) 10ms~30ms Netzwerklatenz beim Redis-Zugriff und (2) zusätzliche Infrastrukturkosten durch Redis-Lese- und Schreibgebühren.

Durch die Kombination der im September 2025 offiziell als GA (Generally Available) freigegebenen Cloudflare Native Workers Rate Limiting API (ratelimits-Binding) mit der Cloudflare Edge WAF (Web Application Firewall) lässt sich ein perfekter 3-stufiger Edge-Schutzschild mit $0 zusätzlichen Server-/Redis-Infrastrukturkosten und 0ms Latenz aufbauen.

In diesem Artikel behandeln wir detailliert die Mechanik von Denial of Wallet, die Implementierung der Cloudflare Native Rate Limiting API (env.RATE_LIMITER), die Konfiguration von WAF-Edge-Regeln, die Hono.js-Middleware-Integration sowie Benchmarks zur Abwehr realer Angriffsszenarien.

Redis Rate Limiting vs. Cloudflare Native Rate Limiting API

Mehrschichtige 3-Stufen-Edge-Verteidigungsarchitektur (Layered Edge Defense)

Um Cloud-Rechnungsexplosionen vollständig zu blockieren, muss eine Verteidigungslinie in einer 3-stufigen Schichtarchitektur aufgebaut werden.

+-----------------------------------------------------------------------------------+
| Cloudflare 3-Stufen-Edge-Verteidigungspipeline (Layered Edge Defense)              |
+-----------------------------------------------------------------------------------+

[Bösartiger DDoS- / Scraper-Bot-Traffic]
         |
         v
 [Layer 1: Cloudflare Edge WAF Rules] ------------> (Automatische 0.1ms-Sperre vor Worker-Ausführung / $0 Kosten)
         | (Nur legitime IPs / Pakete passieren)
         v
 [Layer 2: Native Worker Rate Limiting API] ------> (env.RATE_LIMITER: Limit von 100 Anfragen/Min. pro IP/User)
         | (Gibt sofort HTTP 429 Too Many Requests zurück)
         v
 [Layer 3: Cloudflare Turnstile] -----------------> (CAPTCHA-Ersatz zur Bot-Verifizierung)
         |
         v
 [Geschützte Backend-Logik / D1 DB / OpenAI API] (Sichere Ausführung)

1. Layer 1 (Cloudflare Edge WAF): Bösartige Botnets oder bekannte Spam-IP-Bereiche werden am Edge-Knoten blockiert, noch bevor der Worker-Code überhaupt ausgeführt wird. (Ausführungsanzahl der Worker wird auf 0 reduziert, wodurch $0 Kosten entstehen)
2. Layer 2 (Native Workers Rate Limiting API): Legitime Benutzer, die in kurzer Zeit zu viele Anfragen senden (basierend auf IP, API-Key oder Benutzer-ID), werden über env.RATE_LIMITER.limit({ key }) pro Minute/Sekunde identifiziert und erhalten sofort ein HTTP 429 Too Many Requests.
3. Layer 3 (Cloudflare Turnstile): Bei kritischen Formulareingaben (Registrierung, Zahlung, LLM-Prompt-Anfragen) werden Bots durch unsichtbare Verhaltensmusterprüfungen vollständig herausgefiltert.

Schritt 1: Deklaration des Native Rate Limiting in wrangler.jsonc

Deklarieren Sie das ratelimits-Binding in Cloudflare Workers.

// wrangler.jsonc
{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "edge-dow-defense",
  "main": "src/index.ts",
  "compatibility_date": "2026-01-01",
  "compatibility_flags": ["nodejs_compat"],

  // Offizielle GA Native Rate Limiting Binding Deklaration (2025/2026)
  "ratelimits": [
    {
      "binding": "API_RATE_LIMITER",
      "namespace_id": "1001", // Eindeutige Namespace-ID im Konto
      "simple": {
        "limit": 60,         // Maximale Anzahl zulässiger Anfragen
        "period": 60          // Zeitfenster (in Sekunden: 60 Anfragen pro 60 Sekunden erlaubt)
      }
    },
    {
      "binding": "STRICT_AUTH_LIMITER",
      "namespace_id": "1002",
      "simple": {
        "limit": 5,          // Login-/Passwort-Versuche: Max. 5 Versuche pro 60 Sekunden
        "period": 60
      }
    }
  ]
}

Schritt 2: Aufbau der serverlosen Hono.js-Middleware

Erstellen Sie eine Middleware, die die Native Rate Limiting API am Einstiegspunkt der Worker-Anwendung integriert.

Praxiserprobter Code in src/index.ts

// src/index.ts
import { Hono } from "hono";
import { cors } from "hono/cors";

type Env = {
  Bindings: {
    API_RATE_LIMITER: RateLimiter;
    STRICT_AUTH_LIMITER: RateLimiter;
  };
};

const app = new Hono<Env>();

app.use("*", cors());

// -------------------------------------------------------------------
// 1. Globale IP-basierte Native Rate Limiting Middleware (Layer 2)
// -------------------------------------------------------------------
app.use("/api/*", async (c, next) => {
  // Echte Client-IP aus dem Cloudflare-Edge-Header extrahieren
  const clientIP = c.req.header("cf-connecting-ip") || "anonymous";

  // Native Rate Limiter ausführen (0ms Latenz!)
  const { success } = await c.env.API_RATE_LIMITER.limit({ key: clientIP });

  if (!success) {
    console.warn(`[DoW Defense] Rate limit exceeded for IP: ${clientIP}`);
    return c.json(
      {
        error: "Too Many Requests",
        message: "Anfrage-Limit überschritten. Bitte versuchen Sie es in 1 Minute erneut.",
      },
      429,
      {
        "Retry-After": "60",
      }
    );
  }

  await next();
});

// -------------------------------------------------------------------
// 2. Strenger Rate Limiter speziell für Login-/Auth-Routen
// -------------------------------------------------------------------
app.post("/api/auth/login", async (c) => {
  const clientIP = c.req.header("cf-connecting-ip") || "anonymous";

  // Schutz vor Brute-Force-Angriffen bei fehlgeschlagenen Logins (Max. 5 Versuche pro Minute)
  const { success } = await c.env.STRICT_AUTH_LIMITER.limit({ key: `auth:${clientIP}` });

  if (!success) {
    return c.json(
      { error: "Auth Lockout", message: "Maximale Anzahl an Passwortversuchen überschritten." },
      429
    );
  }

  // Logik zur Passwortprüfung ausführen...
  return c.json({ success: true, token: "jwt_token_sample" });
});

// -------------------------------------------------------------------
// 3. Benutzerdefiniertes Rate Limiting basierend auf API-Key / JWT
// -------------------------------------------------------------------
app.post("/api/v1/llm-generate", async (c) => {
  const authHeader = c.req.header("authorization") || "";
  const apiKey = authHeader.replace("Bearer ", "") || "guest";

  // Limitierung pro API-Key statt pro IP anwenden (Drosselung pro Einzelkunde)
  const { success } = await c.env.API_RATE_LIMITER.limit({ key: `apikey:${apiKey}` });

  if (!success) {
    return c.json({ error: "API Key Rate Limit Exceeded" }, 429);
  }

  // Teure OpenAI / Claude API-Aufrufe ausführen (geschützt!)
  return c.json({ response: "AI Generated Content" });
});

export default app;

Schritt 3: Einrichtung von Cloudflare Edge WAF-Regeln (Layer-1-Schutz)

Die Native Worker Rate Limiting API verhindert teure DB-Abfragen oder LLM-Aufrufe innerhalb der Worker-Logik. Um jedoch die Worker-Aufrufe selbst zu verhindern, müssen Cloudflare Dashboard Edge WAF Custom Rules parallel eingesetzt werden.

WAF Custom Rule 1: Wahllose Bot-Blockierung (Threat Score)

(cf.threat_score gt 15 or http.request.version eq "HTTP/1.0") -> Block

Anfragen mit einem Bedrohungswert (Threat Score) von 15 oder höher sowie veraltete HTTP/1.0-Bot-Anfragen werden sofort vor der Worker-Ausführung blockiert.

WAF Custom Rule 2: API-Pfad-Blockierung bei mehr als 100 Anfragen/Min. (Edge WAF Rate Limit)

1. Wählen Sie im Cloudflare Dashboard Security > WAF > Rate limiting rules
2. Rule Name: Block API Abuse DoW
3. Expression: (http.request.uri.path starts_with "/api/")
4. Rate: 100 requests per 1 minute
5. Action: Block (Duration: 10 minutes)

Sobald diese WAF-Regel angewendet wird, werden Angriffs-IPs, die 100 Anfragen pro Minute überschreiten, nicht einmal mehr an eine Worker-Instanz weitergeleitet, sondern im globalen Cloudflare Edge Backbone-Netzwerk in nur 0.1ms verworfen (drop).

Benchmark: Kosten- und Leistungsindikatoren bei 100.000 wahlloosen DDoS-/Scraper-Angriffen

Vergleichsbericht zu Kosten und Leistung nach Verteidigungsarchitektur bei einem bösartigen Paketangriff mit 100.000 Anfragen (Minute Attack).

DoW-Verteidigungsarchitektur-Vergleichstabelle

Fazit: Schützen Sie Ihr Cloud-Budget vor Denial-of-Wallet-Angriffen

Cloud und Serverless bieten hervorragenden Entwicklungskomfort und Skalierbarkeit. Öffentliche APIs ohne Sicherheitsmaßnahmen werden jedoch schnell zum Ziel von Denial-of-Wallet-Angriffen (DoW), die Unternehmen in den Ruin treiben können.

Die Kombination aus Cloudflares Native Workers Rate Limiting API (env.RATE_LIMITER) und Edge WAF bietet folgende überragende Vorteile:

1. 100 % Schutz vor Rechnungsexplosionen: Traffic wird direkt vor teuren DB-Abfragen, LLM-APIs oder externer Kommunikationslogik gedrosselt.
2. 0ms Latenz: Höchste UX-Geschwindigkeit durch In-Process V8-Edge-Prüfung ohne externe Redis-Kommunikation.
3. $0 zusätzliche Infrastrukturkosten: Nutzung integrierter Cloudflare-Laufzeitfunktionen ohne Speicher- oder Drittanbieter-Abonnements.
4. Mehrschichtige Edge-Sicherheit: Unüberwindbare 3-fache Verteidigungslinie aus WAF, Native Rate Limiter und Turnstile.

Wenden Sie die Native Rate Limiting API noch heute auf Ihre Backend-API-Routen an und bauen Sie eine zu 100 % sichere Serverless-Architektur auf, die jedem bösartigen Traffic-Angriff standhält.

Verwandter Artikel: Im Leitfaden Cloudflare Workers + Passkey (WebAuthn) Authentifizierung mit $0 Kosten ohne Auth0/Clerk finden Sie weitere Details zum Aufbau sicherer Edge-Authentifizierung.