How to Protect APIs from DDoS Attacks

Protect apis from ddos: Identify what is being exhausted

A saturated network connection requires upstream help; application code cannot recover bandwidth that is already full. An HTTP flood may instead exhaust worker slots, database connections or a costly endpoint at a modest request rate. Authentication does not prevent an attacker from consuming resources with valid or invalid credentials.

Record request rate, concurrency, latency, errors, origin bandwidth and dependency saturation. Compare endpoints and authenticated customers against a normal baseline. Avoid declaring an attack from a universal requests-per-second number: legitimate traffic and request cost differ.

Put mitigation before the origin

Use a provider whose protection covers the actual protocol and service. An HTTP reverse proxy protects traffic that passes through it; it does not automatically protect every exposed port. Restrict direct origin access to the intended gateway or provider using the deployment’s supported controls, and verify that health checks and required service paths still work.

Keep an escalation contact and a record of how to enable stricter controls. Check limits, supported traffic and contractual protection before an incident. Cloudflare’s proxy limitations illustrate why product scope matters.

Use more than one rate-limit key

• Before authentication: apply coarse network and request-size limits to reduce cheap abuse.
• After authentication: limit by a validated account, tenant or credential identity.
• Per endpoint: budget expensive searches, exports and uploads separately.
• Across the service: cap concurrency and downstream work so many compliant clients cannot collectively overload it.

An arbitrary X-API-Key value is not a validated customer identity. Attackers can rotate invented values unless authentication constrains them. Likewise, trust forwarded client-IP headers only from your configured proxies. Cloudflare’s rate-limiting guidance provides endpoint and identity examples; available features depend on the product and plan.

Know the scope of your counters

NGINX’s limit_req_zone creates shared memory for workers on that instance. It does not by itself synchronize all independent servers. The documented optional synchronization feature is separate. Requests whose configured key is empty are not counted by that zone. Read the NGINX module documentation.

For a distributed quota, choose an edge capability or shared counter design with suitable atomicity and failure behavior. Decide what happens if the counter store fails, and avoid making that store an unbounded dependency. A local limit can still be useful, but label it as local.

Bound expensive work and keep API responses usable

Set request-body and pagination limits, database timeouts, queue bounds and cancellation behavior. Cache only responses that are safe to share, using keys that preserve tenant and authorization boundaries. Do not cache private responses into a public cache simply to reduce load.

Use API-compatible rejections and documented retry behavior. Browser JavaScript challenges can break SDKs, webhooks and server-to-server callers. Cloudflare’s Under Attack mode documentation describes an interstitial challenge; test it against actual clients before considering it for API routes.

Test the policy before and during rollout

1. Measure representative legitimate bursts and expensive requests in an authorized test environment.
2. Check multiple instances, empty credentials, invalid keys and attempts to bypass the gateway.
3. Test shared-NAT users, mobile networks, webhooks and trusted partner clients for accidental blocking.
4. Observe the proposed rules in logging or dry-run mode where supported, then enforce gradually.
5. Record who can roll back a rule and what metric triggers escalation.

Configuration syntax and limits vary by version and provider. Use supported examples from current documentation and validate them in your environment rather than copying an unexplained universal snippet.

Create an endpoint-cost and client checklist

Inventory expensive routes such as search, exports, uploads, login and operations that call a paid downstream service. Record authentication requirements, request/body bounds, concurrency, timeouts and the actual resource each consumes. A single requests-per-second limit does not represent all endpoint costs.

Test ordinary SDKs, mobile clients and webhooks as well as browsers. Include expected bursts, shared networks, expired credentials and pagination. A browser challenge that works on a website can break a noninteractive API client. Keep tenant-specific responses out of shared caches unless the cache key and authorization behavior have been designed and tested for that use.

Verify rejection, retry and failure behavior

Document the status and response body clients receive when limits apply. Where a service uses 429 and Retry-After, ensure the SDK respects that contract with bounded backoff and a retry ceiling; immediate retries can amplify load. Distinguish a throttled request from an authorization failure or a server fault in monitoring.

Decide what happens when the shared counter or policy service is unavailable: fail-open and fail-closed behavior have different availability and abuse consequences. Test the chosen behavior in an authorized, bounded environment. Roll out changes gradually, track successful legitimate requests and downstream load, and keep a reviewed rollback path rather than measuring success by blocked requests alone.

Frequently asked questions about protect apis from ddos