API Security Best Practices for Production APIs

Modern OAuth 2.0/OIDC with PKCE and short-lived tokens (a 15-minute access token, not a token that lives for a week) has become the baseline for API authentication, and MFA at login closes the most common account-takeover path: a leaked password alone. But authentication only answers "who is this," not "what can they touch" — and that second question is where most real API breaches actually happen.

The attack that shows up over and over in breach reports is BOLA — Broken Object Level Authorization. A user is fully authenticated, holds a valid token, and simply changes an ID in the request (`/orders/42` to `/orders/99`) to read or modify someone else's data. The API checked *who* made the request but never checked whether that user was allowed to touch *that specific object*. This is consistently the top item on the OWASP API Security Top 10 for a reason: it's invisible in code review unless someone is specifically looking for it, and it doesn't require breaking encryption or stealing a token — just changing a number.

Closing this gap means checking authorization at three levels on every request, not just at login: object-level (does this user own or have access to this specific record), function-level (is this role even allowed to call this action, regardless of which object), and field-level (which fields in the response should this caller actually see). A support agent role might legitimately call the same endpoint as a customer, but should never see the same fields.

Least privilege applies to both what a client can *do* and what data it *gets back*. It's common for an API to return an entire internal record — salary, internal IDs, role flags — because it was convenient to serialize the whole database object, even though the caller only needed a name and an ID. Every extra field returned is a field that can leak through a misconfigured client, a logging pipeline, or a browser extension with too much access. Scope tokens narrowly (a mobile app reading order status doesn't need a scope that can also cancel orders), and filter response payloads down to exactly what the caller needs, not what happened to be on the object.

Encryption in transit is the other half of minimizing exposure, and it's easy to think of as "done" once TLS terminates at the edge — but that's often where real coverage stops. Traffic between your API gateway and internal services frequently runs unencrypted on the assumption that the internal network is trusted, which is exactly the assumption that turns a single compromised internal host into full lateral access. Mutual TLS (mTLS) between internal services means each side authenticates the other with a certificate, not just the connection being encrypted — closing the gap between "encrypted" and "actually mutually authenticated."

Signing keys and client secrets are the material an attacker needs to forge valid tokens or impersonate a trusted client — which makes them a higher-value target than almost any single API endpoint. Storing them in a secrets manager backed by an HSM (hardware security module), rather than in environment variables or config files checked into a repository, means the raw key material never needs to be visible to a human or copy-pasted between systems. The unglamorous but critical part is rotation: a secret that's never rotated is a secret that, once leaked (via a misconfigured CI log, a debug endpoint, an old backup), stays valid indefinitely.

On the input side, schema validation at the edge — before a request reaches business logic — rejects malformed input cheaply instead of letting it flow deeper into the system. A request with an unexpected field, an oversized payload, or a malformed URL should get a fast, generic 400 response at the perimeter, not a stack trace three layers into your service after it's already touched a database query. This is the same principle as a bouncer checking ID at the door instead of security discovering an underage patron at the bar: reject early, reject cheaply, and don't let untrusted input reach code that assumes it's already valid.

Rate limiting, payload caps, and request timeouts exist to stop one client — malicious or simply buggy — from degrading the API for everyone else. A limit of 100 requests per minute, a 1MB request cap, and a 30-second timeout aren't arbitrary numbers; they're a statement about what normal usage looks like, with anything beyond that treated as abuse until proven otherwise. These limits should be enforced at the gateway, before the request reaches application code that has to spend real resources processing it.

Generic rate limiting isn't enough for the flows that attackers specifically target: login, checkout, signup, and OTP verification. These "sensitive business flows" need their own defense layer, because a rate limit generous enough for normal checkout traffic is also generous enough for a credential-stuffing bot working through a leaked password list. Velocity rules (flagging unusually rapid attempts from one identity or IP), idempotency keys (preventing a retried checkout from double-charging a customer), CAPTCHA, and step-up MFA (requiring a second factor specifically when a flow looks risky, not on every login) work together to make these flows expensive to automate at scale without adding friction to the vast majority of legitimate users.

Security conversations focus heavily on inbound requests, but outbound calls your own API makes — to partner APIs, webhooks, or internal services — are an attack surface too. Server-Side Request Forgery (SSRF) is the attack that exploits this: if your API accepts a URL from user input and fetches it server-side without restriction, an attacker can point that fetch at your cloud provider's internal metadata endpoint (`169.254.x.x`) and potentially extract credentials your own server has access to. An egress gate that allowlists approved destinations, blocks internal/link-local IP ranges by default, and validates the shape of partner responses closes this path without requiring you to trust every URL a user or partner might supply.

Hardening configuration and error handling closes the gaps that don't require a sophisticated attack at all — just a default that was never locked down. "Deny by default" means explicitly allowing only the HTTP methods, origins, and routes a service actually needs, rather than allowing everything and trying to remember to block the dangerous parts. Strict CORS policies, explicitly locked-down allowed methods, and debug mode forced off in production prevent an API from handing an attacker a detailed stack trace, an open OPTIONS response, or a debug endpoint that was only ever meant for local development.

You can't secure an API you don't know exists. Shadow APIs — endpoints deployed without going through the same review, documentation, or security process as the rest of the system — and forgotten legacy versions (a `/v1/` route everyone assumes is dead but is still reachable) are consistently where real incidents originate, precisely because nobody was watching them. An API registry that tracks every API, its version, and its status (active, deprecated, sunset) turns "we didn't know that was still running" from a plausible excuse into something that shows up on a dashboard before it becomes an incident.

The last layer is detection and response, because prevention will eventually fail somewhere — the goal is making sure failure is noticed in minutes, not discovered months later in a breach report. Audit logs should capture authentication and authorization decisions, admin actions, and configuration changes specifically (not just generic request logs), because those are the events that matter most during an investigation. Feeding those logs into a SIEM with real-time alerting on anomalies — a spike in 401 responses, an unusual pattern of admin actions — is what turns logging from a compliance checkbox into something that actually catches an attack while it's happening rather than after the damage is already done.