Cloudflare Rate Limiting API & WAF: Stop Denial of Wallet

A New Threat in the Serverless Era: Denial of Wallet (DoW)

In traditional on-premise or virtual machine environments (EC2/Compute Engine), a Distributed Denial of Service (DDoS) attack maxes out CPU at 100% and crashes your server. This was traditionally known as Denial of Service.

However, in serverless and edge computing environments (AWS Lambda, Vercel, Supabase, Cloudflare Workers) and LLM API services (OpenAI, Anthropic Claude) where pay-as-you-go billing applies, a DDoS attack or relentless scraping by malicious bots won’t just bring down your service—it will trigger a massive, terrifying infrastructure bill.

This is the most devastating vulnerability in modern cloud security: Denial of Wallet (DoW).

[Denial of Wallet (DoW) Real-World Attack Scenario (As of 2026)]
- Developer launches a side project / startup API (Vercel + Supabase / Lambda + OpenAI API)
- Malicious botnet generates 100,000 API requests per minute
- Result: Automatic charge of $5,000–$12,000 on credit card within a single day

Previously, developers built rate limiting manually to block these attack bursts by storing request counters in external Redis (Upstash, Redis ElastiCache) or Workers KV.

However, this approach suffered from two major limitations: (1) 10ms–30ms network latency incurred when querying Redis, and (2) additional infrastructure costs caused by Redis read/write operations.

By combining the Cloudflare Native Workers Rate Limiting API (ratelimits binding)—which achieved Generally Available (GA) status in September 2025—with Cloudflare Edge WAF (Web Application Firewall), you can construct a bulletproof 3-tier edge defense system with 0ms latency and $0 extra infrastructure cost.

In this article, we will cover everything from the mechanics of Denial of Wallet to implementing Cloudflare Native Rate Limiting API (env.RATE_LIMITER), configuring WAF Edge rules, integrating Hono.js middleware, and benchmark results under live attack conditions.

Redis Rate Limiting vs Cloudflare Native Rate Limiting API

Layered Edge Defense Architecture

To completely prevent cloud billing spikes, you must establish defense lines across a 3-tier architecture.

+-----------------------------------------------------------------------------------+
| Cloudflare 3-Tier Edge Defense Pipeline (Layered Edge Defense)                    |
+-----------------------------------------------------------------------------------+

[Malicious DDoS / Scraper Bot Traffic]
         |
         v
 [Layer 1: Cloudflare Edge WAF Rules] ------------> (Auto-blocked in 0.1ms before Worker executes / $0 spent)
         | (Only legitimate IPs / traffic pass through)
         v
 [Layer 2: Native Worker Rate Limiting API] ------> (env.RATE_LIMITER: Limit 100 requests/min per IP/user)
         | (Immediately returns HTTP 429 Too Many Requests)
         v
 [Layer 3: Cloudflare Turnstile] -----------------> (Silent CAPTCHA alternative for bot verification)
         |
         v
 [Protected Backend Logic / D1 DB / OpenAI API] (Safe Execution)

1. Layer 1 (Cloudflare Edge WAF): Blocks malicious botnets and known spam IP ranges at edge nodes before your Worker code even executes. (Reduces Worker execution count to zero, achieving $0 billing).
2. Layer 2 (Native Workers Rate Limiting API): Evaluates legitimate users sending excessive requests in a short window (filtered by IP, API Key, or User ID) via env.RATE_LIMITER.limit({ key }) per minute/second, returning HTTP 429 Too Many Requests.
3. Layer 3 (Cloudflare Turnstile): Filters out bots completely during critical form submissions (signup, checkout, LLM prompt requests) using non-intrusive biometrics and behavioral pattern analysis.

Step 1: Declaring Native Rate Limiting in wrangler.jsonc

Declare the ratelimits binding in your Cloudflare Workers configuration.

// 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"],

  // Official GA Native Rate Limiting Binding Declaration (2025/2026)
  "ratelimits": [
    {
      "binding": "API_RATE_LIMITER",
      "namespace_id": "1001", // Unique namespace ID within your account
      "simple": {
        "limit": 60,         // Maximum allowed requests
        "period": 60          // Time window (in seconds: 60 requests allowed per 60s)
      }
    },
    {
      "binding": "STRICT_AUTH_LIMITER",
      "namespace_id": "1002",
      "simple": {
        "limit": 5,          // Login/password attempts: 5 requests per 60s
        "period": 60
      }
    }
  ]
}

Step 2: Building Hono.js Serverless Middleware

Build middleware that integrates the Native Rate Limiting API into your Worker application entry point.

src/index.ts Production Code

// 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. Global IP-based Native Rate Limiting Middleware (Layer 2)
// -------------------------------------------------------------------
app.use("/api/*", async (c, next) => {
  // Extract real client IP from Cloudflare edge header
  const clientIP = c.req.header("cf-connecting-ip") || "anonymous";

  // Execute Native Rate Limiter (0ms latency!)
  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: "Rate limit exceeded. Please try again in 1 minute.",
      },
      429,
      {
        "Retry-After": "60",
      }
    );
  }

  await next();
});

// -------------------------------------------------------------------
// 2. Strict Rate Limiter for Login/Auth Routes
// -------------------------------------------------------------------
app.post("/api/auth/login", async (c) => {
  const clientIP = c.req.header("cf-connecting-ip") || "anonymous";

  // Defend against brute force login attempts (5 requests per minute limit)
  const { success } = await c.env.STRICT_AUTH_LIMITER.limit({ key: `auth:${clientIP}` });

  if (!success) {
    return c.json(
      { error: "Auth Lockout", message: "Maximum password attempt limit exceeded." },
      429
    );
  }

  // Execute login credential verification logic...
  return c.json({ success: true, token: "jwt_token_sample" });
});

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

  // Apply rate limit per API Key instead of IP (Per-user throttling)
  const { success } = await c.env.API_RATE_LIMITER.limit({ key: `apikey:${apiKey}` });

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

  // Perform expensive OpenAI / Claude API call (Protected!)
  return c.json({ response: "AI Generated Content" });
});

export default app;

Step 3: Configuring Cloudflare Edge WAF Rules (Layer 1 Defense)

While the Native Worker Rate Limiting API prevents expensive DB queries and LLM calls inside your Worker logic, blocking Worker execution entirely requires pairing it with Cloudflare Dashboard Edge WAF Custom Rules.

WAF Custom Rule 1: Block Malicious Bots (Threat Score)

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

Requests with a Threat Score above 15 or legacy HTTP/1.0 bot requests are dropped instantly before reaching Worker execution.

WAF Custom Rule 2: Block API Abuse Exceeding 100 Requests/Min (Edge WAF Rate Limit)

1. Go to 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)

When this WAF rule is applied, attacking IPs that exceed 100 requests per minute are dropped in 0.1ms at Cloudflare’s global edge backbone network without even initializing a Worker instance.

Benchmark: Cost & Performance Metrics Under 100,000 Burst Attacks

Here is a performance and cost comparison report across defense architectures during a 100,000-request burst attack (Minute Attack).

DoW Defense Architecture Comparison

Conclusion: Protect Your Cloud Wallet from Denial of Wallet Attacks

While cloud and serverless platforms provide exceptional developer ergonomics and scalability, unprotected public APIs remain vulnerable targets for Denial of Wallet (DoW) attacks that can bankrupt projects overnight.

Combining Cloudflare’s Native Workers Rate Limiting API (env.RATE_LIMITER) with Edge WAF delivers remarkable advantages:

1. 100% Protection from Billing Spikes: Throttle traffic completely upstream of expensive DB queries, LLM APIs, and external HTTP calls.
2. 0ms Latency Overhead: In-process V8 edge verification avoids external Redis round-trips to deliver peak user experience.
3. $0 Additional Infra Costs: Built directly into the Cloudflare runtime without third-party subscriptions or external storage fees.
4. Layered Edge Security: Create an invincible 3-tier defense using WAF + Native Rate Limiter + Turnstile.

Apply the Native Rate Limiting API to your backend API routes today, and build a 100% secure serverless architecture that stays resilient against malicious traffic bursts.

Related reading: Check out our guide on building zero-cost edge authentication using Cloudflare Workers + Passkeys (WebAuthn) without Auth0 or Clerk to further strengthen your edge application security.