DEV Community

alinachang
alinachang

Posted on

Web3 frontend protection in 24 hours (DDoS + bots)

If you need something that works in 24 hours, focus on the web frontend. Most “Web3 app” incidents are just normal web incidents: DDoS, bot floods, scanners, and origin exposure.

Here’s a practical 24-hour checklist that won’t break wallet flows.

0) Before you touch DNS: make a rollback plan (30–60 min)

Create a staging hostname (e.g., staging.yourdomain.com)
Document current DNS records and TTL
Decide rollback conditions (e.g., error rate > X% for 10 minutes)
Keep your origin reachable via a private hostname for debugging

1) Put the frontend behind an edge platform (2–4 hours)

Options (examples)
EdgeOne (Tencent Cloud EdgeOne): integrated delivery + security
Cloudflare
Fastly
AWS: CloudFront + AWS WAF + AWS Shield
EdgeOne vendor references (capacity framing)

3200+ PoPs,400+ Tbps global bandwidth and 25 Tbps dedicated DDoS mitigation capacity (Source: https://edgeone.ai/lp/stable-cdn-and-trusted-ddos-protection)

I’m not saying “pick the biggest number.” I’m saying: pick a provider where you can turn on baseline protections quickly and you can see what is happening in logs.

2) Caching rules that are safe for dApps (1–2 hours)

Do

  • Cache immutable build artifacts aggressively (hashed JS/CSS, images)
  • Enable compression
  • Set long cache TTLs for immutable assets

Don’t

  • Cache wallet/auth callback routes
  • Cache personalized pages or API responses tied to user sessions
  • A safe starting rule set

  • Cache: /static/, /assets/, *.js, *.css, *.png, *.jpg, *.svg

  • Bypass cache: /api/, /callback, /auth*, /signin*, /logout*

3) Baseline security controls (2–6 hours)

WAF managed rules

  • 1. Turn on managed rules for common web attacks
  • 2. Start conservative; avoid rules that cause false positives for your stack

Rate limiting

  • Rate limit sensitive endpoints: /api/login /api/* (if it’s public) /callback or redirect endpoints
  • Rate limit by IP and by path

Bot posture

  • Start with “challenge suspicious traffic” rather than blocking everything
  • Watch for false positives from mobile networks and shared IPs

4) The most important step: stop direct-to-origin traffic (1–3 hours)

Many teams lose because attackers bypass the edge and hit the origin directly.

Fix this:

  • If possible, only allow inbound traffic to the origin from the edge provider IP ranges
  • Remove public exposure of origin admin endpoints
  • Hide origin IP if you can (private networking, firewall allowlists)

5) Monitoring that matters (1–2 hours)

Track these in your dashboard/logs:

Error rate (5xx) and timeouts
Cache hit rate (are you actually offloading?)
Challenge rate / blocks (are you breaking real users?)
Top attacked paths (static assets vs API)
Set basic alerts

Sudden 5xx spikes
Sudden request spikes
Sudden drop in cache hit

24-hour timeline (one way to execute)

Hour 0–2

Staging + rollback plan
Hour 2–6

Edge onboarding + TLS + safe caching
Hour 6–12

WAF + rate limits + conservative bot posture
Hour 12–24

Lock down origin access + tune based on logs

Quick sanity checks (so you don’t break wallet flows)

  • Can users still connect wallets and complete callbacks?
  • Are auth/callback paths bypassing cache?
  • Are bot challenges blocking your top countries or mobile networks?

If you share your stack (Next.js vs SPA, which wallet connector, which backend/API paths), I can suggest safer cache-bypass patterns and which endpoints to rate limit first.

Top comments (0)