Protect Serverless APIs from Denial-of-Wallet Attacks

Serverless architectures automatically scale up to meet incoming demand, but this dynamic scalability creates a critical vulnerability: Denial-of-Wallet (DoW) attacks. Unlike traditional Denial-of-Service attacks that aim to knock infrastructure offline, DoW attacks leverage massive automated request floods to exhaust financial resources rather than compute capacity. Protecting serverless endpoints requires implementing edge-level traffic filtering, strict concurrency limits, intelligent request caching, and automated spending circuit breakers.

Edge Filtering with Web Application Firewalls (WAF)

The most effective way to prevent costly serverless executions is to block malicious requests before they hit backend compute environments. Teams deploy Web Application Firewalls (WAFs) and edge networks, such as AWS CloudFront, Cloudflare, or Azure Front Door, directly in front of their APIs.

Configuring managed rulesets at the edge filters out known botnets, Layer 7 volumetric attacks, and geo-specific anomalies. Applying CAPTCHA or managed challenges at the edge ensures that only legitimate human traffic triggers function invocations, dropping malicious payloads without incurring invocation costs.

API Gateway Rate Limiting and Throttling

Placing an API gateway in front of serverless functions allows engineering teams to enforce usage tiers and rate limits. By configuring client-based token buckets, teams set hard ceilings on requests per second (RPS) and burst limits.

Throttling rules should be implemented granularly:

• Per IP address: Mitigates unauthenticated, single-source volumetric floods.
• Per API key or user ID: Prevents compromised accounts or scraper scripts from running unbounded workloads.
• Global endpoint limits: Protects internal services from systemic upstream failures.

When an incoming wave of requests exceeds these thresholds, the API gateway returns an HTTP 429 (Too Many Requests) error instantly, terminating the request without calling the underlying compute function.

Setting Concurrency Limits

Public cloud providers allow teams to enforce concurrency limits on serverless workloads. Setting reserved concurrency for individual functions caps the total number of simultaneous executions a specific function can run.

While exceeding reserved concurrency results in dropped requests, it guarantees that a runaway traffic spike will not scale horizontally indefinitely. This creates a hard financial ceiling, containing maximum potential spend during a sustained attack while preserving unreserved concurrency pools for other critical application services.

Validation and Caching Prior to Execution

Serverless endpoints that process heavy database queries or third-party API calls are particularly expensive to run. Teams reduce compute runtimes and total invocations by offloading work upstream:

• Schema Validation at Gateway: Configure the API gateway to validate request bodies, query parameters, and headers against an OpenAPI schema. Malformed or malicious requests are rejected before invoking compute resources.
• Aggressive Response Caching: Cache non-personalized responses at the CDN or API gateway layer. If an attacker floods a read-heavy endpoint, cached responses are served directly from edge memory without executing a single serverless invocation.

Automated Billing Alarms and Circuit Breakers

Real-time monitoring is critical to arresting DoW events in their early stages. Development teams pair infrastructure metrics with cloud financial monitors (such as AWS Budgets or Google Cloud Billing alerts).

Beyond passive notifications, resilient teams deploy automated circuit breakers. When billing or invocation thresholds hit critical anomalies, automated runbooks trigger mitigation scripts—such as dialing down function concurrency to zero, changing API gateway routes to return static error responses, or temporarily detaching public routing. This emergency cut-off prevents financial devastation while engineers identify and mitigate the attack vector.