API Security
Build a threat model and protect APIs against injection, abuse, credential theft, data exposure, and common API vulnerabilities.
Threat Modeling an API
Security begins by identifying assets, trust boundaries, attackers, entry points, and possible impacts.
For an API, assets can include personal data, access tokens, financial records, source code, administrative actions, and internal infrastructure.
Attack surfaces include endpoints, file uploads, query parameters, authentication flows, webhooks, integrations, GraphQL or query-like interfaces, and administrative APIs.
Think in terms of confidentiality, integrity, availability, authentication, authorization, accountability, and abuse prevention.
Injection and Unsafe Input
Injection occurs when untrusted input is interpreted as part of a command or query.
Examples include SQL injection, NoSQL injection, shell injection, template injection, LDAP injection, and command injection.
Use parameterized queries, safe query builders, allowlists, schema validation, escaping appropriate to the output context, and least-privilege database accounts.
Do not assume that using MongoDB makes an application immune to injection. Query objects, operators, aggregation pipelines, and dynamic expressions still require careful validation.
Do not directly pass req.body, req.query, or req.params into database query APIs without validation and controlled mapping.
Rate Limiting
Rate limiting protects APIs from accidental overload, brute-force attacks, scraping, credential attacks, and abusive clients.
Common algorithms include fixed window, sliding window, token bucket, and leaky bucket.
Limits may be applied per IP, user, API key, organization, endpoint, or a combination. Distributed deployments generally need a shared rate-limit store such as Redis rather than process-local counters.
A rate-limited request commonly receives 429 Too Many Requests, optionally with Retry-After.
Common API Security Failures
Important API risks include broken object-level authorization, broken authentication, unrestricted resource consumption, broken function-level authorization, unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration, improper inventory management, unsafe consumption of APIs, and excessive exposure of sensitive fields.
Security testing should verify both positive and negative authorization cases. Testing only successful requests is insufficient.
Security must be enforced on the server. Client-side hiding of buttons is not authorization.
- Authorization must be enforced server-side.
- Every object identifier is an authorization boundary.
- Rate limiting protects both availability and abuse-sensitive operations.
- API security requires continuous testing and monitoring.