APIs are among the most attractive DDoS targets on the internet, and the reason is economics. An HTML page can be cached and served from an edge for almost nothing; an API call is the opposite — it is rarely cacheable, it usually runs a database query or two, and its endpoints are often documented publicly so an attacker knows exactly which ones are expensive. The result is a nasty asymmetry: a few hundred cheap requests per second can pin your backend at 100% CPU while your marketing site keeps returning 200 OK, so the outage is invisible until customers start complaining that the app does not work.
Defending an API is therefore less about raw traffic volume and more about the cost of each request. The goal is to make an abusive request cost the attacker something, and to make an expensive endpoint reject anything that is not a legitimate, authenticated caller.
Why REST APIs Get Hit
- Endpoint enumeration: your own documentation reveals every expensive operation, so attackers skip the reconnaissance and go straight for the search, export and report routes.
- Stateless authentication: JWTs make it trivial for a bot to hold thousands of parallel 'authenticated' sessions without any server-side session cost to the attacker.
- Uncached responses: unlike a static page, most API responses are dynamic, so every single request reaches your database.
- Webhook and callback floods: any endpoint that accepts inbound POSTs (payment callbacks, integrations) is a target that also cannot be challenged, because the caller is a machine.
Why GraphQL Is Worse
GraphQL concentrates all of these risks behind a single endpoint that is designed to be flexible — which is exactly what an attacker exploits.
- Introspection abuse: one query returns your entire schema, handing an attacker a map of every expensive field.
- Query-depth attacks: a deeply nested query can force exponential joins on the database from a single small request.
- Batched queries: hundreds or thousands of operations can be packed into one HTTP request, so per-request rate limiting counts it as one.
- Aliased fields: the same expensive field can be requested thousands of times under different aliases in a single query.
How to Harden an API
- Rate-limit per API key or token, not just per IP — an attacker rotates IPs but the credential (or its absence) is the real identity.
- Set per-endpoint limits: /search or /export deserve far tighter limits than /health or /product.
- Disable GraphQL introspection in production and enforce query depth and complexity limits.
- Require authentication even on 'public' endpoints that are expensive to serve, so anonymous floods are rejected cheaply at the edge.
- Cache whatever is cacheable, even briefly — a 10-second cache on a hot read collapses a flood into a handful of origin hits.
The cost asymmetry is the whole game
A good API defence flips the economics: make the attacker's request expensive (a challenge, a rejected token, a rate-limit) and your response cheap (a cached or refused answer). You are not trying to out-scale the attacker; you are trying to make the attack not worth running.
Where Akarguard Fits
Akarguard sits in front of your API as a Layer 7 reverse proxy, so every request is inspected before it reaches your origin, and your origin IP stays hidden so it cannot be attacked directly. You set per-domain and per-endpoint rate and connection limits from the panel, apply WAF rules to block malformed or malicious payloads, and let automatic mitigation raise protection when a flood is detected. Non-browser clients like payment callbacks and API consumers are handled with rate limiting and filtering rather than an interstitial challenge they could never solve. It does not replace good API design — depth limits, auth and caching are still yours to set — but it gives you the enforcement point in front of the app to apply them.