API Security Best Practices: Protecting Modern Web APIs from Real Attacks

Why API Security Deserves Dedicated Attention#

APIs are the primary attack surface for modern web applications. Unlike server-rendered HTML applications where user interactions are mediated through a browser's security model, APIs are directly accessible to any HTTP client — including automated attack tools.

The OWASP API Security Top 10 documents the most commonly exploited API vulnerabilities based on real-world incidents. This guide covers each category with practical mitigation strategies.

Authentication & Authorization Foundations#

Authentication: Verifying Identity Every API endpoint that accesses user data or performs mutations must verify the caller's identity. The two primary mechanisms:

• Bearer Tokens (JWTs): The client includes an Authorization: Bearer header. The server validates the token's signature and expiry. JWTs are stateless but cannot be instantly revoked.
• Session Tokens: An opaque identifier stored in an HttpOnly cookie. The server looks up session data on each request. Instantly revocable but requires server-side session storage.

Authorization: Verifying Permission Authentication proves who you are. Authorization proves what you are allowed to do. These are separate concerns and must be enforced separately.

Broken Object Level Authorization (BOLA) is the most commonly exploited API vulnerability. It occurs when an API endpoint allows users to access other users' objects by manipulating identifiers.

Example vulnerable endpoint: GET /api/invoices/12345 — if any authenticated user can access any invoice by knowing the ID, this is BOLA. The fix: always verify that the requesting user owns or has explicit permission to access the specific object being requested.

Input Validation and Injection Prevention#

Never trust input from API clients. Validate every field in every request:

• Schema validation: Use Zod, Joi, or JSON Schema to declare the exact shape, types, and constraints of expected input. Reject requests that don't conform before touching business logic.
• SQL Injection prevention: Always use parameterized queries or ORM-generated queries. Never concatenate user input into SQL strings.
• NoSQL Injection: Validate and sanitize MongoDB query operators — user-controlled operators like $where can execute arbitrary JavaScript.
• Command Injection: Never pass user input to shell commands. If shell execution is unavoidable, use explicit allow-lists and sanitization.

Rate Limiting and Abuse Prevention#

• Credential stuffing (automated login attempts)
• Data scraping (systematic enumeration of your dataset)
• DoS via expensive operations (complex queries, file processing)

• Global rate limit: Maximum requests per IP per minute (prevents naive DoS)
• Endpoint rate limit: Stricter limits on expensive or sensitive endpoints (login: 5/minute, password reset: 3/hour)
• User-level rate limit: Prevents authenticated abuse even from legitimate users

Return standard HTTP 429 Too Many Requests with a Retry-After header when limits are exceeded.

CORS Configuration#

CORS (Cross-Origin Resource Sharing) prevents browsers from making unauthorized cross-origin API requests. Key configuration rules:

• Never use Access-Control-Allow-Origin: * for APIs that handle authenticated data
• Maintain an explicit allow-list of permitted origins
• Do not reflect the Origin header back without validation — this is equivalent to allowing all origins
• Specify Access-Control-Allow-Methods and Access-Control-Allow-Headers explicitly

Security Headers for APIs#

Even for JSON APIs, security headers prevent certain attack vectors:

• Content-Type: application/json — specify the response content type explicitly
• X-Content-Type-Options: nosniff — prevent MIME type sniffing
• Strict-Transport-Security — enforce HTTPS connections
• Remove X-Powered-By headers that reveal your technology stack

Logging and Monitoring for Security#

Security without observability is incomplete. Log the following for every API request:

• Timestamp, request ID, authenticated user ID (not PII like email)
• HTTP method, path, status code, response time
• IP address and User-Agent for abuse pattern detection
• Authentication failures (failed login, expired token, invalid signature)

• Passwords, tokens, or API keys
• Full request bodies containing sensitive user data (PCI, HIPAA compliance)
• Query parameters containing credentials

Alert on authentication failure spikes, unusual access patterns, and requests for non-existent resources (potential enumeration attacks).