LESSON 29.4
Protecting APIs from abuse
Defending services against DDoS, malicious payloads, SQL injection, credential stuffing, and perimeter API abuse.
5 min read
Public API endpoints face constant automated scanning, scraping, Distributed Denial of Service (DDoS) floods, and exploitation attempts from botnets and adversaries.
Securing APIs requires defense in depth: inspecting traffic at the edge, enforcing strict schema validation before processing, and preventing malicious payloads from interacting with backend databases.
Input validation and parameterized queries
The most catastrophic vulnerabilities (SQL injection, command injection, and remote code execution) occur when untrusted user input is concatenated directly into system commands:
Bad: db.Execute("SELECT * FROM users WHERE email = '" + inputEmail + "'")
Good: db.Execute("SELECT * FROM users WHERE email = ?", inputEmail)- Parameterized queries: Always use prepared statements or Object-Relational Mappings (ORMs). The SQL engine pre-compiles the query syntax tree; user parameters are transmitted out-of-band as raw values that cannot alter query logic.
- Strict schema validation: Enforce strict JSON schemas (Zod, JSON Schema, Protobuf) at the API gateway layer. Reject unknown fields, validate data types, enforce string length bounds, and discard malformed payloads before they reach internal application code.
- Allowlist validation: Where possible, validate inputs against known-good allowlists (e.g. enum values, ISO currency codes) rather than attempting to filter out known-bad characters with regular expressions.
Rate limiting and abuse mitigation
Attackers use automated scripts to launch credential stuffing (testing stolen password lists), scrape proprietary data, or overwhelm backend services:
Per-IP Rate Limiting
- Prevents a single host from flooding API endpoints with thousands of requests/sec
- Defeated by distributed botnets rotating thousands of residential IP addresses; harms corporate users behind shared NAT gateways
Pick it when: Perimeter DDoS protection at Cloudflare or AWS WAF.
Per-Account Rate Limiting
- Tracks failed login attempts per username or email address, stopping credential stuffing regardless of incoming IP addresses
- Can cause Denial-of-Service for legitimate users if an attacker intentionally locks their account
Pick it when: Authentication, checkout, and password reset endpoints.
Web Application Firewalls (WAF)
Deploying a Web Application Firewall (WAF) at the perimeter (Cloudflare, AWS WAF, Fastly) shields upstream infrastructure:
- Perimeter DDoS absorption: Edge networks absorb Layer 3 and Layer 4 volumetric SYN and UDP floods before traffic reaches your origin servers.
- Managed rule sets: Inspects incoming HTTP payloads for OWASP Top 10 attack signatures (Cross-Site Scripting, SQL Injection, Log4j, Remote File Inclusion).
- Bot management: Evaluates client browser TLS fingerprints (JA3/JA4 fingerprints) and JavaScript challenge tokens to distinguish genuine browser users from automated headless scrapers.
Cross-Origin Resource Sharing (CORS)
Browsers enforce the Same-Origin Policy, prohibiting client-side scripts from reading responses from a different origin unless explicitly permitted by the destination server via CORS headers:
- Never return
Access-Control-Allow-Origin: *on endpoints that accept authentication cookies (Access-Control-Allow-Credentials: true). - Strictly validate the incoming
Originrequest header against an explicit list of approved trusted domains.
- Max failed login attempts before lockout
- 5 to 10 attempts per account
- Account lockout cooldown duration
- 15 to 30 minutes
- Maximum API request body size
- 1 MB to 10 MB limit enforced at ingress
- HTTP request timeout at edge
- 15 to 30 seconds max to prevent slowloris attacks
Try it
Distributed API Rate Limiter HLD
Design an edge rate-limiting and abuse mitigation system that defends against distributed credential stuffing attacks.