Preventing API DoS Without Breaking Legitimate Traffic

API Denial of Service Is Often an Economics Problem

Many teams conceptualize API hizmet reddi (Denial of Service — DoS) purely as a request volume problem — enough inbound traffic to saturate bandwidth or exhaust connection limits. That model is incomplete. More frequently, API DoS is an economics problem: the attacker identifies an endpoint where they can force disproportionately expensive backend work — full-table database scans, complex joins, heavyweight search index queries, file generation operations, or chained third-party API calls — at a marginal cost to themselves that is trivial compared to the computational burden imposed on the target.

Cost Amplification Attack Patterns

The economics of API DoS become clearer when you examine cost amplification patterns — the specific ways attackers turn cheap requests into expensive backend operations:

| Attack Pattern | Attacker Cost | Defender Cost | Example |

|---------------|---------------|---------------|---------|

| Unbounded search | 1 HTTP request | Full-table DB scan | GET /vulns?q=* with no pagination |

| Deep pagination | 1 HTTP request | Large offset DB query | GET /export?page=50000 |

| Nested aggregation | 1 HTTP request | Multi-join computation | GET /stats?group=vendor&subgroup=product&subsubgroup=version |

| File generation | 1 HTTP request | CPU-intensive rendering | GET /export?format=pdf&rows=100000 |

| Chained third-party calls | 1 HTTP request | N×external API latency+cost | Bulk translation with per-item AI inference |

Understanding which of your endpoints fit these patterns is the first step. Rate limiting alone does not stop cost amplification — an attacker can stay under any per-IP rate limit while still triggering the most expensive path on every single request.

Rate Limiting Strategy by Scope

A layered rate limiting strategy accounts for different abuse identities. A per-IP limit alone is trivially bypassed with distributed infrastructure. A complete strategy needs all four scopes:

| Scope | Recommended Limit (example) | Purpose |

|-------|---------------------------|---------|

| Per-IP | 100 req/min for reads, 10 req/min for writes | Block anonymous probing |

| Per-user | 300 req/min authenticated | Allow normal usage, catch abuse |

| Per-tenant | 1,000 req/min total | Protect shared infrastructure from noisy neighbors |

| Global | Circuit-breaker at 80% capacity | Last-resort availability protection |

Why Rate Limiting Alone Is Not Enough

Rate limiting is a necessary control but an insufficient one in isolation. A comprehensive API resilience model must also account for:

endpoint cost asymmetry, where some operations are orders of magnitude more expensive than others regardless of request volume.

authentication state and abuse identity to distinguish anonymous probing from authenticated misuse.

pagination discipline to prevent unbounded result set extraction.

query complexity limits for search and filter operations that can be made arbitrarily expensive.

graceful degradation and backpressure mechanisms that preserve service availability during overload rather than simply failing hard.

The Design Goal Is Fairness, Not Just Blocking

Effective API DoS prevention protects service availability without penalizing legitimate high-volume consumers unnecessarily. That requires the control strategy to accurately distinguish normal high-usage patterns from hostile amplification behavior — a distinction that requires behavioral context, not just threshold comparisons.

MyVuln Perspective

MyVuln is most useful in this area when external exposure inventory, observed API weakness patterns, and abuse signal data are correlated in a single view. The platform surfaces which externally exposed API paths carry the highest risk of being weaponized into operational cost amplification or service availability degradation — giving security teams a prioritized remediation list rather than a generic statement that denial of service is theoretically possible.

API availability degrades when teams apply uniform rate limits as though every endpoint carries identical backend cost. In practice, the compute, I/O, query count, external service latency, and memory consumption of a simple lookup endpoint and a bulk export, aggregation, or PDF rendering endpoint can differ by orders of magnitude. Applying the same request-count limit to both means that a legitimate, expensive operation can be weaponized as a denial-of-service vector by any authenticated user — not just an adversary.

Effective API DoS defense begins with a cost model. A practical endpoint classification:

| Endpoint type | Cost profile | Rate limit approach |

|---|---|---|

| Simple record lookup | Low CPU, single DB query | High req/min, per-user |

| List with filters | Medium I/O, indexed query | Medium req/min, per-user |

| Time-series aggregation | High CPU, full-scan potential | Low req/min, queue |

| Bulk export (CSV/JSON) | High I/O, row limit enforced | Very low req/hr, async |

| PDF rendering | High CPU + memory | Concurrency cap (e.g. 2 simultaneous) |

| Fan-out to N downstream | Variable, unpredictable | Per-request timeout + circuit breaker |

Without measurement, rate limits remain intuitive guesses. Reporting, bulk search, tenant-scoped list generation, time-series aggregation, and PDF construction endpoints are where cost variance is most visible — and where a single poorly metered request can exhaust shared infrastructure for all tenants.

The second defensive layer is controlled degradation design. Rather than allowing the entire system to slow simultaneously under load, expensive code paths should be progressively throttled, predictable queries should be absorbed by caching layers, concurrency controls should bound the number of simultaneously executing heavy operations, and clients should receive consistent, well-documented error behavior. The objective is not simply to halt an attack — it is to consciously decide which users retain service continuity under pressure while capacity is constrained. A well-designed API availability strategy does not produce a system that is closed to everyone; it produces a system capable of making principled admission decisions when resources are under strain.