APIs are the connective tissue of modern applications. Mobile apps, single-page web apps, partner integrations, and microservices all communicate through APIs. Every API endpoint is an attack surface. If your API handles authentication, processes payments, or returns sensitive data, a vulnerability in any endpoint can lead to a breach.
The OWASP API Security Top 10 highlights the most critical API risks, including broken object-level authorization, broken authentication, excessive data exposure, and lack of rate limiting.
Every API request must be authenticated and authorized. Common approaches include:
API keys are simple but limited. They identify the calling application but not the end user. They should be transmitted in headers (not URL parameters, which get logged) and rotated regularly.
OAuth 2.0 with bearer tokens is the standard for user-facing APIs. The client obtains an access token from an authorization server and includes it in the Authorization header. Use short-lived access tokens with refresh token rotation.
Mutual TLS (mTLS) provides strong machine-to-machine authentication. Both the client and server present certificates, ensuring both parties' identities are verified.
Authorization must be enforced at every endpoint. The most common API vulnerability is Broken Object Level Authorization (BOLA): an authenticated user accesses resources belonging to another user by manipulating object IDs in the request. Always verify that the authenticated user has permission to access the specific resource they are requesting.
Never trust input from API consumers. Validate every parameter: type, length, format, and range. Reject requests that do not conform to your API schema.
For REST APIs, use a schema validation library that checks request bodies against an OpenAPI specification. For GraphQL, enforce query depth limits, complexity limits, and field-level authorization.
SQL injection, command injection, and path traversal are all possible through API parameters. Use parameterized queries, avoid constructing commands from user input, and sanitize file paths.
Without rate limiting, an attacker can brute-force authentication, scrape your data, or overwhelm your servers. Implement rate limits based on API key, user identity, IP address, or a combination.
Return appropriate HTTP status codes: 429 (Too Many Requests) when limits are exceeded. Include Retry-After headers to tell legitimate clients when to try again.
For authentication endpoints, implement stricter limits and consider exponential backoff after failed attempts.
APIs often return more data than the client needs. A user profile endpoint might return the user's email, phone, address, and internal database ID when the client only needs the name and avatar. This excessive data exposure increases the impact of any vulnerability.
Design API responses to return only the fields the client requires. Implement field-level filtering and avoid directly serializing database models into API responses.
All API traffic must use HTTPS. There are no exceptions. HTTP API endpoints can be intercepted, modified, and replayed. Enforce TLS 1.2 or later with strong cipher suites.
For APIs that handle especially sensitive data, consider certificate pinning in mobile apps to prevent man-in-the-middle attacks even when the device's trust store has been compromised.
Log all API requests with sufficient detail for security analysis: timestamp, source IP, authenticated identity, endpoint, HTTP method, response code, and response time. Do not log sensitive data like passwords or tokens.
Monitor for anomalies: unusual request volumes, spikes in authentication failures, access patterns that suggest automated scraping, and requests to endpoints that do not exist (which may indicate reconnaissance).