APIs now sit behind nearly every mobile app, SaaS product, and integration a business relies on — which also makes them the most consistently exploited attack surface in modern software. Most API breaches don't involve a novel exploit; they involve a well-known best practice that simply wasn't implemented. This is a practical checklist of the ones that matter most.
1. Authentication: Never Trust a Request by Origin Alone
Every API endpoint that touches non-public data needs to independently verify who's calling it — not assume trust because a request came from your own frontend. Token-based authentication (OAuth 2.0, signed JWTs with short expiry) should be the default, with API keys reserved for server-to-server integrations, never exposed in client-side code.
Action Point: Search your frontend codebase for any API key or secret embedded directly in client-side JavaScript. If you find one, rotate it immediately and move that call server-side.
2. Authorization: Verify Object-Level Access, Not Just Endpoint Access
The single most common API vulnerability in real-world audits is broken object-level authorization — an endpoint that checks whether a user is logged in, but not whether that specific user is allowed to access the specific record they're requesting. /api/orders/12345 should verify the requesting user actually owns order 12345, every single time, not just that they're authenticated.
Why this gets missed so often
It gets missed because it works perfectly in every manual test — the developer testing the feature is naturally testing with their own account and their own records. The gap only appears when someone deliberately requests a record that isn't theirs, which is exactly what an attacker does first.
3. Rate Limiting and Throttling
- Apply rate limits per user and per IP address, not just globally across the whole API
- Set tighter limits on sensitive endpoints (login, password reset, payment) than on general read endpoints
- Return generic error messages on rate-limit rejection — don't reveal whether the limit was hit due to invalid credentials or genuine abuse
4. Input Validation on Every Parameter, Every Time
Validate type, length, format, and range on every input an API accepts — including query parameters and headers, not just request bodies. This single practice closes off SQL injection, NoSQL injection, and a large share of denial-of-service vectors that rely on malformed or oversized input.
5. Don't Leak Data Through Over-Fetching
A common pattern in fast-moving development is returning the entire database object from an endpoint and letting the frontend pick which fields to display. This quietly exposes internal fields, other users' partial data, or fields that were never meant to leave the server. Every API response should explicitly whitelist the fields it returns.
The data that gets breached is rarely the data your API was designed to expose. It's the data that came along for the ride because nobody explicitly excluded it.
6. Encrypt in Transit, and Verify You Actually Are
TLS everywhere is table stakes in 2026 — but it's worth periodically verifying with an actual scan, not assuming, since misconfigured load balancers and internal service-to-service calls are common places where encryption quietly drops.
7. Log Access, Not Just Errors
Security logging that only captures errors misses the pattern that matters most: a legitimate-looking sequence of successful requests that, taken together, represents a data-scraping attack or a slow-and-steady privilege escalation attempt. Log who accessed what, when, so that pattern is visible after the fact.
8. Versioning and Deprecation Discipline
Old API versions left running "just in case" are a common source of breaches, because they often predate security fixes applied to the current version. Set an explicit deprecation timeline for every API version, and enforce it — a v1 endpoint with none of your v3 security hardening is a standing invitation.
A Simple Audit You Can Run This Week
- Pick your five most-used API endpoints
- For each, verify: does it check object-level ownership, not just authentication?
- For each, verify: does the response only include fields the frontend actually uses?
- Check whether rate limiting exists on your login and password-reset endpoints specifically
None of these fixes require new infrastructure — they require someone deliberately checking for the gap, which is exactly the kind of review that tends to get skipped when a team is moving fast and the API "already works."
