DDoS Protection for Web Apps: What You Need

# DDoS Protection for Web Apps: What You Need

Distributed denial-of-service (DDoS) attacks are no longer the exclusive problem of banks and gaming companies. Botnets-for-hire mean anyone with a grudge and a few dollars can point thousands of compromised devices at your app. This guide explains what these attacks look like and the layered defenses that keep you online.

What a DDoS attack actually does

The goal is simple: exhaust a resource so legitimate users cannot get through. The resource might be bandwidth, CPU, memory, connection table slots, or an upstream database. Attacks fall into three broad buckets, mapped loosely to the OSI model.

Volumetric attacks try to clog your pipe. Protocol attacks exhaust connection-tracking resources in firewalls and load balancers. Application-layer attacks are the sneakiest — they look like real traffic (valid HTTP requests) but hammer expensive endpoints like search or login.

Why you cannot just "add a server"

The largest recorded attacks have exceeded the multi-terabit range. No single origin server survives that. The defense has to happen upstream, at a network with enough capacity to absorb and filter the flood before it ever reaches you. This is why DDoS protection is fundamentally a job for a CDN or scrubbing network, not your application code.

Layered defense

Real protection is layered. No single control stops everything.

1. Anycast + a large edge network

Anycast routing announces the same IP from many global locations. A volumetric attack gets spread across dozens of data centers instead of concentrated on one. Providers like Cloudflare, Akamai, and AWS Shield run networks with capacity measured in tens of Tbps for exactly this reason.

2. Rate limiting

Cap how many requests a single client (by IP, token, or fingerprint) can make in a window. This blunts application-layer floods. A simple nginx example:

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
  location /api/ {
    limit_req zone=api burst=20 nodelay;
    proxy_pass http://backend;
  }
}

Rate limiting belongs at the edge first (where it scales) and in your app second (as defense in depth).

3. A Web Application Firewall

A WAF inspects L7 traffic and blocks known-bad patterns. It can distinguish a real browser from a crude bot and challenge suspicious clients with a JavaScript or CAPTCHA test.

4. Caching

The cheapest request is the one your origin never sees. Aggressive edge caching of static assets and cacheable API responses means an HTTP flood mostly hits the CDN, not your servers.

5. Autoscaling — with caution

Autoscaling can absorb legitimate spikes, but scaling up in response to a malicious flood just hands the attacker a way to run up your cloud bill (a "denial-of-wallet" attack). Pair autoscaling with rate limits and budget caps.

Detecting an attack

Know the signs so you can react:

• Sudden traffic spike from unusual geographies or a narrow set of ASNs.
• A flood of requests to a single expensive endpoint.
• Rising error rates and latency with no deploy to explain it.
• Connection-table or memory exhaustion on edge nodes.

Good observability — request-rate dashboards, per-endpoint latency, and alerting — turns a panicked midnight investigation into a routine response.

What to build vs buy

Be honest about this. You should not build volumetric DDoS protection yourself. You cannot outrun a terabit flood from a single origin. Buy it — from a CDN or your platform.

What you *should* own:

• Application-layer rate limits on expensive endpoints.
• Sensible timeouts and connection limits.
• Caching everything cacheable.
• Budget alerts so an attack does not become a surprise invoice.

How PandaStack handles it

PandaStack runs apps behind Cloudflare DNS and Kong ingress on multi-region GKE, with DDoS protection and an application firewall built in. Static assets are served from the edge, and free-tier apps even scale to zero behind the proxy. You inherit network-level absorption without configuring scrubbing centers yourself — your job shrinks to setting sensible app-level rate limits.

References

• [Cloudflare: What is a DDoS attack?](https://www.cloudflare.com/learning/ddos/what-is-a-ddos-attack/)
• [OWASP Denial of Service Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html)
• [AWS Best Practices for DDoS Resiliency (AWS Shield)](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/welcome.html)
• [NIST SP 800-61: Computer Security Incident Handling Guide](https://csrc.nist.gov/pubs/sp/800/61/r2/final)

---

DDoS defense is about layers and upstream capacity, not heroic origin servers. PandaStack puts your apps behind a global edge with DDoS protection and a WAF by default — try it on the free tier at [dashboard.pandastack.io](https://dashboard.pandastack.io).