How to Defend API Endpoints Against CC Attacks? Rate-Limit and Signature FAQ

APIs have no cache fallback and are the easiest CC targets to knock over. Covers typical CC symptoms, Nginx rate-limit config, layered rate-limit keys, signature anti-replay, captcha placement, and the role of WAF/high-defense. Configs are copy-ready.

API endpoints have no page-cache fallback. Every request hits the database and business logic. They are the most common CC target. This FAQ covers typical CC symptoms on APIs, Nginx rate-limit config, how to pick rate-limit keys, signature anti-replay, where to put captcha, and the real role of high-defense WAF in API protection.

Q: Why are APIs especially easy to knock down with CC attacks?

Compared with normal pages, APIs are natural high-value CC targets:

• No cache layer as fallback: pages can be static and CDN-cached; every API request needs live compute and a DB hit.
• High per-request cost: one stats endpoint can trigger multi-table joins; attackers turn small traffic into large resource burn.
• Reusable auth credentials: once a token leaks or there is no auth, attackers replay without limit.
• Uniform response format: attackers can tell success easily and auto-tune attack parameters.

Q: What are typical signs when an API is under CC?

Watch these signals:

• An endpoint's QPS jumps several times over the daily baseline, with no matching business growth.
• DB connection pool saturates, slow queries spike, latency goes from tens of ms to several seconds.
• Bandwidth is not necessarily high—CC is often small-packet high-frequency; traffic graphs look normal while CPU/DB collapse first.
• Logs show large volumes of repeated requests with the same UA, empty Referer, or a fixed source IP range.

Quickly locate which endpoint is hit:

`awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10`

Q: How to rate-limit APIs at the Nginx layer?

Baseline is IP-dimension request rate limiting plus connection limits, both at once:

`limit_req_zone  $binary_remote_addr zone=api_ip:10m   rate=10r/s;
limit_conn_zone $binary_remote_addr zone=api_conn:10m;

server {
    location /api/ {
        limit_req  zone=api_ip   burst=20 nodelay;
        limit_conn zone=api_conn 10;
        limit_req_status 429;
        proxy_read_timeout 10s;
        ...;
    }
}`

Key params: rate=10r/s is 10 requests per second average per IP; burst=20 nodelay allows a 20-request burst, extras rejected immediately with no queue; limit_conn 10 caps concurrent connections per IP at 10; limit_req_status 429 returns 429 instead of the default 503 so clients can recognize rate limiting. Set thresholds after load-testing the endpoint's normal peak; better too loose than too tight.

Q: Why is IP-only rate limiting not enough? How should the key be chosen?

Attackers use proxy pools and rotating dial IPs; swapping IPs costs almost nothing. Correct approach is layered rate limiting: IP layer as a coarse filter for random probes, business-key layer as fine control against targeted attacks. For authenticated endpoints, token or user ID is a more accurate key:

`map $http_authorization $api_key {
    ""      $binary_remote_addr;
    default $http_authorization;
}
limit_req_zone $api_key zone=api_token:10m rate=30r/s;

server {
    location /api/ {
        limit_req zone=api_token burst=50 nodelay;
        ...;
    }
}`

Even if the attacker rotates hundreds of IPs, as long as they share a few tokens they still get limited. For high-risk endpoints such as SMS and login, add a third-layer key on phone number or target account.

Q: How to do signature verification and anti-replay?

Rate limiting caps how many. Signatures decide whether the call is allowed at all. Standard approach:

• Client HMAC-SHA256-signs request params + timestamp + random nonce. Do not ship the secret in frontend-visible plaintext.
• Server checks the signature matches and the timestamp is inside a ±300 second window; reject if outside.
• Write the nonce to Redis with a TTL equal to the time window; a duplicate is a replay attack—reject immediately.

`# Server-side verification pseudocode (Python)
sign = hmac.new(secret, params + ts + nonce, hashlib.sha256).hexdigest()
if sign != client_sign:      reject(401)
if abs(now - ts) > 300:      reject(403)   # time-window anti-replay
if redis.exists("nonce:" + nonce): reject(403)
redis.setex("nonce:" + nonce, 600, 1)`

All three checks are required, especially nonce anti-replay—many APIs only check timestamp, so the same request replayed hundreds of thousands of times inside the 5-minute window still works.

Q: Where should captcha and bot checks sit?

Not every endpoint should pop captcha; the wrong layer hurts real users:

• Login, register, password reset, SMS send: front-load image captcha or behavioral captcha. These are credential-stuffing and SMS-bomb hotspots.
• Site-wide request entry: JS challenge, cookie checks—leave to WAF or CDN at the edge so origin resources are not consumed.
• Business APIs themselves: rate limit + signature first; captcha only as a trigger—after a key hits rate limit, require a captcha token on retry.

Q: What do high-defense and WAF actually do for API CC protection?

Nginx rate limiting and signatures run at origin; attack traffic already reached your server. When CC volume is large, origin bandwidth and connections can fill first. WAF/high-defense value is moving the line forward: frequency analysis, UA fingerprinting, JS challenge, and bot checks at the cloud edge; only good requests go back to origin. Products like Baidu Cloud Protection have dedicated CC frequency-fingerprint policies; with CDN edge nodes absorbing attack traffic, origin barely notices during an attack. Self-built rate limiting is the baseline skill; putting a WAF in front is the low-maintenance fix. They do not conflict.

Q: After a CC hit, can I just block IP ranges?

Works as emergency, not as a long-term method:

• Blocking a /24 easily hits ISP NAT egresses; one egress sits behind hundreds or thousands of real users.
• Proxy pools switch ranges cheaply; block one range and the attacker jumps to the next.
• Ban must be automated + short TTL: fail2ban-style tools that ban/unban from logs, not handmade permanent iptables rules.

Suggested order: rate limit first (429 circuit-break) → auto temp-ban IPs that trip rate limit often → consider long bans only for ranges with clear malicious fingerprints.

Q: Any extra advice?

API CC defense is a system. Four notes: 1) build QPS baseline alerts so you know within 5 minutes of an attack—far better than looking at dashboards after the fact; 2) keep a degrade plan—non-core endpoints under attack return a static 503 and protect the core transaction path; 3) load-test rate-limit rules before they go live; knock your own endpoints over once so you know where the threshold is; 4) if the team cannot maintain this stack, use a cloud WAF with CC protection—hand edge rate limiting, bot checks, and attack reports to a specialist product and keep engineering time on the business.