API Security Hub

This hub consolidates practical API security guides for engineering teams shipping fast APIs and SPAs. Most API breaches come from three sources: CORS misconfigurations that expose credentials to attackers, missing or bypassable authentication on endpoints, and insufficient rate limiting that enables abuse and enumeration. The guides below address each of these systematically.

Start here: the most critical API risks

If your team is new to API security hardening, read these first:

• API Security Best Practices 2026 — comprehensive guide covering auth, input validation, rate limiting, schema enforcement, and monitoring.
• How to Fix CORS Misconfiguration — step-by-step fix guide with before/after examples for wildcard origins, credential exposure, and preflight issues.
• What Is CORS? — concept-level explanation for developers new to cross-origin policy.

Implementation guides by framework

• CORS Policy Examples: Express, Laravel, Next.js, Nginx — copy-paste production CORS configs for four common stacks.
• API Rate Limiting Guide: Throttling & Abuse Prevention — token bucket, sliding window, and per-endpoint strategies.
• React & Next.js Security Checklist 2026 — env leak, source map, API route auth, and CSP for modern JS apps.

Why CORS is the most common API security failure

CORS misconfiguration is consistently the most frequently detected finding across API security scans. The root cause is almost always the same: developers set Access-Control-Allow-Origin: * to fix a failing browser request during development and then deploy that configuration to production without understanding the implications.

A wildcard Access-Control-Allow-Origin combined with Access-Control-Allow-Credentials: true is the most dangerous CORS configuration possible. It allows any website on the internet to make authenticated requests to your API using the victim's session cookies. This is not theoretical — it is a direct, exploitable path to account takeover.

The correct fix is an explicit allowlist of trusted origins validated server-side. The CORS fix guide walks through the exact server-side validation logic for Express, Laravel, Django, and Nginx.

API authentication hardening: the fundamentals

Authentication failures are ranked #1 in the OWASP API Security Top 10 (API1:2023 — Broken Object Level Authorization and API2:2023 — Broken Authentication). The two most common patterns:

• Missing authentication on sensitive endpoints: Internal APIs, admin endpoints, and reporting routes are frequently deployed without authentication under the assumption that they are not publicly known. Attackers enumerate these paths through direct URL probing and source map analysis.
• Predictable or guessable object IDs: Sequential integer IDs (/api/users/1234) allow attackers to iterate through all records. Use UUIDs or implement object-level authorization that checks ownership on every request — not just role.
• JWT implementation flaws: Common JWT mistakes include accepting alg: none, using weak secrets, not validating expiration, and trusting the kid header to load verification keys. Use a battle-tested JWT library and validate every claim.
• API key exposure: API keys in JavaScript source files, GitHub repos, and browser-readable environment variables are discovered by automated scanners within hours. Rotate any exposed key immediately and audit the exposure window.

Rate limiting: what most teams get wrong

Rate limiting is frequently implemented incorrectly — or not at all — on the endpoints that matter most. The most dangerous endpoints without rate limiting are not home pages; they are authentication endpoints, password reset flows, OTP verification, and any enumeration-friendly resource endpoint.

• Per-user, not just per-IP: Rate limiting only by IP is bypassed with distributed attacks. Limit by authenticated user ID for logged-in endpoints, and by IP + fingerprint for unauthenticated endpoints.
• Endpoint-specific limits: A blanket 1000 requests/minute limit protects against DDoS but not credential stuffing. Apply tight limits (5-10 attempts per minute) specifically on /login, /reset-password, /verify-otp, and similar flows.
• Return 429 with Retry-After: Always include a Retry-After header in rate limit responses so legitimate clients can back off gracefully without polling indefinitely.

Protecting APIs in production: a quick-start checklist

• All API routes require authentication unless explicitly and intentionally public.
• CORS Access-Control-Allow-Origin is set to an explicit allowlist, never * with credentials.
• Rate limiting is applied to auth, registration, OTP, and all enumeration-sensitive endpoints.
• Input validation rejects unexpected fields and enforces strict types — no passthrough of raw request bodies.
• API responses never include internal error details, stack traces, or database identifiers in production.
• API keys are never stored in client-side code, localStorage, or committed to Git.
• External scan via AI QA Monkey API & CORS scanner is part of the weekly monitoring routine.

OWASP API Security Top 10: what to prioritize in 2026

The OWASP API Security Top 10 (2023 edition) defines the most critical API vulnerabilities based on real-world exploit patterns. Understanding these helps teams prioritize remediation correctly.

• API1 — Broken Object Level Authorization (BOLA): The most common API vulnerability. An endpoint that returns user data based on an ID (/api/users/1234) must verify the authenticated user owns or has access to that object. Attackers increment or enumerate IDs to access other users' data. Fix: server-side ownership check on every data retrieval endpoint.
• API2 — Broken Authentication: Weak authentication mechanisms, no token expiration, accepting passwords without brute-force protection. Fix: short-lived JWTs (15-minute access tokens), refresh token rotation, rate limiting on all auth endpoints.
• API3 — Broken Object Property Level Authorization: Returning more fields than the client needs (over-fetching). An attacker views an API response and finds is_admin: false — then tries to POST is_admin: true. Fix: explicit field allowlists in API responses; server-side validation of all writable fields.
• API4 — Unrestricted Resource Consumption: No limits on request size, rate, or resource usage. A single client can overwhelm the API or generate excessive costs. Fix: request size limits, per-user rate limits, pagination enforcement, and timeout configuration.
• API5 — Broken Function Level Authorization: Admin or privileged endpoints accessible to regular users. Fix: role-based middleware applied to all routes; regular audit of route:list or equivalent to verify authorization on every endpoint.

API versioning and security debt

API versioning creates a common security trap: old API versions remain accessible indefinitely while security fixes are only applied to the current version. v1 endpoints continue to receive production traffic — and vulnerabilities — long after v3 is released.

• Audit all API versions for parity: Every security fix applied to v3 must be backported to v1 and v2, or those versions must be sunset with a migration deadline communicated to API consumers.
• Set and enforce sunset dates: Publish deprecation notices with specific end-of-life dates. After the sunset date, return 410 Gone instead of continuing to serve potentially vulnerable v1 responses.
• Monitor old version traffic: Check what percentage of requests still hit v1 endpoints. If it is non-trivial, proactively reach out to API consumers to assist with migration.
• Apply security middleware equally: Rate limiting, auth checks, input validation, and logging must be configured identically across all active API versions — not just the latest.

Securing API keys and secrets in deployment

API key exposure is consistently one of the fastest paths from external access to production data breach. Keys committed to Git, embedded in frontend bundles, or logged in server output are discovered by automated scanners within hours.

• Never commit secrets to Git: Use .gitignore to exclude .env files. Install a pre-commit hook (using git-secrets or detect-secrets) that blocks commits containing patterns matching API keys, tokens, and passwords.
• Use environment-specific secret stores: AWS Secrets Manager, HashiCorp Vault, GitHub Actions Secrets, or Doppler. Inject secrets at runtime rather than storing them in config files or container images.
• Rotate exposed keys immediately: If a key is found in a public Git repository, assume it has been accessed. Revoke it at the provider level immediately — do not just delete the Git commit. Commit history is searchable; the key must be revoked.
• Use short-lived tokens where possible: OIDC tokens in CI/CD (GitHub Actions OIDC + AWS IAM) eliminate the need for long-lived API keys in pipelines entirely. Tokens expire after the workflow run.

Adjacent controls

• SQL Injection Testing Checklist
• How to Prevent SQL Injection Attacks
• Incident Response Plan Template
• Security Headers Checklist 2026

Explore related hubs

• WordPress Security Hub
• Compliance Security Hub