API Security Best Practices in 2026: The Complete Checklist

APIs are the number one attack surface in modern applications. The OWASP API Security Top 10 lists the most critical risks, and most APIs fail on at least half of them. Here is the complete security checklist every developer needs in 2026.

The OWASP API Security Top 10 (2023 Edition)

The Open Web Application Security Project maintains a dedicated API Security Top 10 list, separate from the general web security list. These are the most common and dangerous API vulnerabilities:

1. API1: Broken Object Level Authorization (BOLA) — Accessing other users' data by changing an ID in the request. The most common API vulnerability.
2. API2: Broken Authentication — Weak authentication mechanisms that allow attackers to impersonate users.
3. API3: Broken Object Property Level Authorization — APIs returning more data than the client needs (mass assignment, excessive data exposure).
4. API4: Unrestricted Resource Consumption — No rate limiting, allowing DoS or expensive queries.
5. API5: Broken Function Level Authorization — Regular users accessing admin endpoints.
6. API6: Unrestricted Access to Sensitive Business Flows — Automated abuse of business logic (ticket scalping, credential stuffing).
7. API7: Server-Side Request Forgery (SSRF) — Tricking the server into making requests to internal resources.
8. API8: Security Misconfiguration — Default configs, verbose errors, missing security headers.
9. API9: Improper Inventory Management — Old/undocumented API versions still accessible.
10. API10: Unsafe Consumption of APIs — Trusting data from third-party APIs without validation.

Authentication: Getting It Right

OAuth 2.0 + OpenID Connect

For user-facing APIs, OAuth 2.0 with OIDC is the standard. Key rules:

• Use the Authorization Code flow with PKCE for SPAs and mobile apps. The implicit flow is deprecated.
• Access tokens should be short-lived (5-15 minutes). Use refresh tokens for session continuity.
• Validate the aud (audience) claim to prevent token confusion attacks.

Decode and inspect JWT tokens with our JWT Decoder. Read our deep dive on how JWT tokens actually work.

API Keys

API keys are suitable for server-to-server authentication where user identity is not needed. They are NOT suitable for client-side apps (anyone can extract the key from browser DevTools).

• Transmit API keys in headers (X-API-Key), never in URLs (URLs are logged).
• Hash API keys in your database. Store SHA-256(key), not the plaintext. Use our Hash Generator to understand hash functions.
• Implement key rotation with overlap periods (old and new key both valid for a transition window).
• Scope keys with minimum permissions. A read-only key should not be able to write data.

Input Validation Checklist

// Express.js example with zod validation
import { z } from 'zod';

const createUserSchema = z.object({
  email: z.string().email().max(254),
  name: z.string().min(1).max(100).regex(/^[a-zA-Z\s-']+$/),
  age: z.number().int().min(13).max(150).optional(),
  role: z.enum(['user', 'editor']),  // allowlist, not blocklist
});

app.post('/api/users', (req, res) => {
  const result = createUserSchema.safeParse(req.body);
  if (!result.success) return res.status(400).json({ errors: result.error.issues });
  // proceed with validated data
});

• Validate all input: body, query params, headers, path params. Assume everything is malicious.
• Use allowlists, not blocklists: Define what IS valid, not what is not.
• Limit string lengths: Prevent oversized payloads from consuming memory.
• Validate content types: Reject requests with unexpected Content-Type headers.
• Parameterize SQL queries: Never concatenate user input into SQL. Use our SQL Formatter to review query structure.

Rate Limiting and Throttling

# Response headers for rate limiting
X-RateLimit-Limit: 100        # max requests per window
X-RateLimit-Remaining: 43     # requests remaining
X-RateLimit-Reset: 1711120060 # UTC epoch when window resets
Retry-After: 30               # seconds to wait (on 429)

• Implement rate limiting per API key, per IP, and per user.
• Use sliding window or token bucket algorithms (not fixed window, which has burst issues at window boundaries).
• Apply stricter limits to authentication endpoints (prevent brute force).
• Return 429 Too Many Requests with Retry-After header. Check our HTTP Status Codes reference.

CORS Configuration

// Secure CORS configuration (Express.js)
app.use(cors({
  origin: ['https://app.example.com', 'https://admin.example.com'],
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true,
  maxAge: 86400  // cache preflight for 24 hours
}));

Never use Access-Control-Allow-Origin: * with credentials. It does not work (browsers reject it) and indicates a misunderstanding of CORS. Read our CORS deep dive.

Security Headers

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Type: application/json; charset=utf-8
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Cache-Control: no-store
X-Request-Id: uuid-for-tracing

Logging and Monitoring

• Log all authentication failures, authorization denials, and validation errors.
• Never log request bodies, passwords, tokens, or API keys. Use our hash generator to create token fingerprints for safe logging.
• Include a unique request ID in every response for correlation.
• Set up alerts for: spike in 401/403 errors, unusual rate limit hits, requests from new geolocations.

The Bottom Line

API security is not optional. Every public API should implement authentication, authorization at every endpoint, input validation, rate limiting, HTTPS, secure CORS, and comprehensive logging. Use the OWASP API Security Top 10 as your checklist and audit regularly.

Related tools and articles: JWT Decoder, Hash Generator, SSL Checker, JWT Tokens Explained, SSL/TLS Guide, and 50+ more free tools.