API Security For Developers: What Every Engineer Should Know
Most API security breaches exploit the same five vulnerabilities. Here is what every developer needs to know about authentication, authorization, rate limiting, and input validation.
APIs are the backbone of modern applications. They are also the most common attack surface. The 2024 OWASP API Security Top 10 lists the most critical risks, and the same patterns appear in breach after breach.
The Five Vulnerabilities That Matter Most
1. Broken Authentication
The most common API vulnerability is weak or missing authentication. APIs that accept any token, have no token validation, or use predictable token generation are trivial to exploit.
JWT is the most common authentication mechanism, but it is frequently implemented incorrectly. Common mistakes include not verifying the signature, accepting tokens with alg: none, using weak secret keys, and not checking token expiration.
Fix: Always verify the JWT signature using the correct secret or public key. Reject the alg: none algorithm. Use strong, randomly generated secrets. Validate exp, nbf, and iss claims. Implement token rotation with short-lived access tokens and refresh tokens.
2. Broken Object Level Authorization
An API endpoint like GET /api/users/:id should only return data if the authenticated user has permission to access that specific user record. Many APIs only check that the user is authenticated, not that they are authorized.
This vulnerability enables IDOR (Insecure Direct Object Reference) attacks. An employee can change the ID in the URL and access another employee's salary information.
Fix: Every endpoint that accesses a specific resource by ID must verify the current user has permission to access that resource. This is not a middleware check. It is a per-resource check that must account for the relationship between the user and the resource.
3. Rate Limiting Deficiency
APIs without rate limiting invite brute force attacks. Attackers can try millions of passwords, enumerate valid user IDs, or scrape large datasets. Without rate limiting, there is no defense against automated attacks.
Fix: Implement rate limiting at multiple levels: per IP address, per user, per API key, and per endpoint. Use sliding window algorithms rather than fixed windows to avoid burst abuse. Return appropriate 429 Too Many Requests responses with Retry-After headers.
4. Mass Assignment
APIs that accept all fields from the request body without filtering allow attackers to set fields they should not control. A user registration endpoint might accept isAdmin: true in the request body and create an administrator account.
Fix: Never pass request data directly to your database models. Define explicit allowed fields for each mutation endpoint. Use Data Transfer Objects (DTOs) or input validation schemas that whitelist permitted fields.
5. Injection
SQL injection, NoSQL injection, and command injection remain common in API implementations. APIs that construct database queries by concatenating user input are vulnerable.
Fix: Use parameterized queries or prepared statements for all database operations. Use an object-relational mapper (ORM) with built-in injection protection. Validate and sanitize all user input. Escape special characters for the specific database engine.
Security Headers Every API Needs
| Header | Purpose | Value |
|---|---|---|
| Content-Type | Prevent content type confusion | application/json |
| X-Content-Type-Options | Prevent MIME sniffing | nosniff |
| X-Frame-Options | Prevent clickjacking | DENY |
| Strict-Transport-Security | Enforce HTTPS | max-age=31536000 |
| Access-Control-Allow-Origin | CORS restrictions | Specific origins only |
Building Security Into The Development Process
Threat Modeling
Before writing code, think about how an attacker might exploit the endpoint. What if they send negative numbers? What if they send array instead of string? What if they omit required fields? This thinking catches vulnerabilities before they reach production.
Automated Security Testing
Integrate security scanning into the CI/CD pipeline. SAST tools catch code-level vulnerabilities. DAST tools catch runtime vulnerabilities. Dependency scanning catches known vulnerabilities in third-party libraries.
API Security Review Checklist
Create a security review checklist that every API endpoint must pass before deployment. Include authentication verification, authorization checks, input validation, rate limiting, and error handling that does not leak implementation details.
API security is not a separate phase or a dedicated team's responsibility. It is a practice that every developer must integrate into how they write code. The five vulnerabilities listed here account for the majority of API breaches. Fixing them eliminates most of the risk.
An API that authenticates users but does not verify their authorization to access specific resources is not secured. It is just gated.
- Broken authentication and broken object-level authorization are the top API risks
- JWT must be implemented with signature verification and claim validation
- Every API endpoint needs per-resource authorization checks
- Rate limiting at multiple levels prevents brute force attacks
- Mass assignment and injection vulnerabilities come from trusting user input






Leave a comment