API Security
API security covers everything from input validation to TLS to rate limiting. We will walk through the threats every API faces and the defenses that handle them, with the OWASP API Top 10 in mind.
The threat landscape
OWASP publishes an API Security Top 10. The current list reads like a tour of every breach you have read about. Broken object level authorization. Broken authentication. Excessive data exposure. Resource exhaustion. Server-side request forgery. Improper inventory management. The defenses are well-known, but they require discipline at every endpoint, not just at the edge.
Defenses you should always have
TLS everywhere
HTTPS for all traffic, public and internal. No exceptions in production. Modern services should reject plain HTTP entirely. HSTS headers force browsers to use HTTPS even if the user types http. mTLS (mutual TLS) for service-to-service is a strong upgrade where both sides verify each other.
Authentication and authorization on every endpoint
Every endpoint that touches user data must verify the caller's identity AND verify they are allowed to do this specific action on this specific resource. The IDOR pattern (Insecure Direct Object Reference) is the most common API bug — the endpoint authenticates but forgets to check ownership.
Input validation
Trust nothing the client sends. Validate types, lengths, ranges, formats. Use a schema validator (JSON Schema, Zod, Pydantic). Reject anything that does not match. Allowlist over denylist whenever possible.
Parameterized queries
SQL injection is still a top vulnerability after 25 years because people still concatenate strings into SQL. Use parameterized queries. Always. Same idea for any other interpreter (NoSQL, shell, LDAP).
Output encoding
If your API returns HTML, encode everything that could be an attack. If it returns JSON, set the correct Content-Type so browsers do not sniff and execute it as something else.
Rate limiting and quotas
Per-user, per-IP, per-API-key. Stops abuse and resource exhaustion. See the rate limiting topic.
Security headers
Modern browsers respect a bunch of HTTP headers that significantly harden your API and the apps that consume it.
Strict-Transport-Security— force HTTPSContent-Security-Policy— control what scripts can loadX-Content-Type-Options: nosniff— block MIME sniffingX-Frame-Options: DENY— block clickjackingReferrer-Policy: no-referrer— control referer leaks
CORS configured carefully
Cross-Origin Resource Sharing. Decides which web origins can hit your API from a browser. Access-Control-Allow-Origin: * is fine for fully public APIs but disastrous for anything authenticated. Allowlist specific origins.
Secrets management
API keys, database passwords, signing keys never go in source code or env files committed to git. Use a vault (AWS Secrets Manager, HashiCorp Vault, Google Secret Manager). Rotate regularly. Never log them.
Logging and monitoring
Log every authentication attempt (success and failure). Log every authorization decision. Log unusual patterns: a user ID accessing thousands of records, an API key suddenly seeing 100x normal traffic, requests from a new country. Without monitoring, breaches go undetected for months. The average is something like 200 days. Better logging cuts that to days.
The mindset
Security is not a feature you bolt on at the end. It has to be a default in the way you build. Every new endpoint is a new attack surface. The cheapest time to fix a vulnerability is at design review. The most expensive time is after the breach hits the news.