If you run services in production, your APIs are your attack surface. The highest-profile API breaches of the past few years did not involve exotic exploits — they were ordinary, well-formed requests asking for objects the caller should never have been allowed to see. The OWASP API Security Top 10 exists because these failure modes repeat with remarkable consistency. Securing an API in 2026 means doing a short list of things rigorously. Here is that list.

Transport: TLS 1.2 or 1.3, Nothing Else

"SSL" has been deprecated for over a decade; when a document still says SSL, read it as TLS and check which versions are actually enabled. Serve TLS 1.3 by default, keep TLS 1.2 as the floor for legacy clients, and disable everything older. Add HSTS so clients never downgrade to plaintext:

# nginx — TLS 1.2/1.3 only, no downgrade to HTTP
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security "max-age=63072000" always;

Authentication: OAuth 2.0 and OIDC, With API Keys in Their Place

For user-facing APIs, the standard is OAuth 2.0 with short-lived access tokens, and OpenID Connect on top when you need verified user identity. For machine-to-machine calls, use the client credentials grant. API keys still have a role, but understand what they are: identifiers, not strong authentication. They are fine for usage attribution and quota enforcement on low-risk endpoints; they are not an access control for sensitive operations. Rotate them, and keep them out of URLs and client-side code. One thing that does not belong on this list is biometrics — a fingerprint authenticates a human to a device; what arrives at your API is still a token, and the token is what you must validate.

JWTs concentrate several classic mistakes. Pin the accepted signing algorithms and reject alg: none; validate exp, iss, and aud on every request; fetch verification keys from the issuer's JWKS endpoint so key rotation works without redeploys; and keep access-token lifetimes in minutes, not days.

Authorization: BOLA Is the Number One API Vulnerability

Broken Object Level Authorization has topped the OWASP API list since 2019, and it remains the most common real-world API flaw: a request for /invoices/8371 carrying a perfectly valid token that belongs to a different customer. The fix is unglamorous — check object ownership on every request, inside the service, where the data relationships live. Two siblings deserve the same treatment: function-level authorization (admin endpoints reachable by non-admin tokens) and property-level authorization, where mass assignment lets a client set fields like role or price that were never meant to be writable. Allow-list the properties clients may send.

Validate Input Against a Schema

Define the API in OpenAPI and enforce that schema at the gateway or in middleware: types, ranges, lengths, formats, and rejection of unknown fields. Injection has not gone away because APIs replaced web forms — anything that reaches a database, a shell, or a template must still be parameterized. Output encoding, often listed alongside these controls, is really an XSS defense for browsers that render your API's data; it protects the client, not the API, so do not count it as an API-side control.

Rate Limiting and Abuse Controls

Set per-client limits keyed to the token or client ID, return 429 with Retry-After, and tune limits per endpoint — login and password-reset routes far tighter than read paths. This one control blunts credential stuffing, object-ID enumeration, scraping, and the resource-exhaustion attacks OWASP files under unrestricted resource consumption. Pair it with request-size and pagination caps so a single expensive query cannot do the attacker's work for them.

Gateways at the Edge, mTLS Inside

An API gateway — AWS API Gateway, Kong, Apigee, or an Envoy-based setup — gives you one place to get TLS termination, token validation, schema checks, rate limits, and WAF integration right, instead of reimplementing them per service. What the gateway cannot do is object-level authorization: that logic stays in the services. For service-to-service traffic, use mutual TLS so both ends authenticate each other; a service mesh such as Istio or Linkerd, or a SPIFFE/SPIRE deployment, issues and rotates workload certificates automatically, which is the only way mTLS survives contact with real operations.

Finally, instrument all of it. Gateway and authentication logs are among the highest-value detection sources you own: stream them into your SIEM and detection pipeline and alert on token anomalies and spikes in 401s and 403s. If you want a structured review of an existing API estate against this checklist, that is exactly the work our SecOps practice does. For platform-specific hardening, AWS's API Gateway protection guide is a solid reference.

Tags: #APISecurity #OAuth2 #mTLS #OWASP