API Security Best Practices: A 2026 Engineering Guide

The classic OWASP Top 10 was written for web pages. APIs have their own failure modes, which is why OWASP maintains a separate API Security Top 10 that leads with authorization rather than injection. We build APIs for a living — our API development practice bakes these defenses in, and our web app pentest tests them. The sections below follow the order that matters in practice, not the order people expect.

Authentication verifies identity. Use a standard rather than rolling your own: OAuth 2.0 / OpenID Connect for user-facing APIs, signed short-lived tokens (JWT or opaque) for service-to-service calls, and scoped API keys only where a full token flow is impractical. The failure mode here is OWASP API2: Broken Authentication — weak tokens, missing expiry, no rotation, or accepting tokens that were never validated.

• Validate token signature, issuer, audience, and expiry on every request — do not trust an unverified token because it "looks right."
• Keep access tokens short-lived; use refresh tokens deliberately.
• Require MFA on the human login that mints those tokens.
• Rate-limit the login and token endpoints (see section 4) to blunt credential stuffing.

ATT&CK link: weak authentication enables Valid Accounts (T1078) and Brute Force (T1110).

Authorization decides what an authenticated caller may do. This is where most real API breaches happen, and it splits into two OWASP entries: API1: Broken Object-Level Authorization (BOLA) and API3: Broken Object Property-Level Authorization. BOLA is the classic: the endpoint trusts an ID from the client instead of checking ownership against the session.

// VULNERABLE — trusts the URL parameter
app.get("/api/orders/:id", auth, async (req, res) => {
  const order = await db.orders.findById(req.params.id);
  return res.json(order); // any logged-in user reads any order
});

// FIXED — scope the lookup to the authenticated owner
app.get("/api/orders/:id", auth, async (req, res) => {
  const order = await db.orders.findOne({
    id: req.params.id,
    ownerId: req.user.id, // ownership enforced server-side
  });
  if (!order) return res.status(404).end();
  return res.json(order);
});

Property-level authorization is the subtler cousin: a user is allowed to update a record but should not be allowed to set every field on it. Mass-assignment bugs let a caller flip role: "admin" or isVerified: true through an update endpoint that blindly spreads the request body.

• Enforce authorization on the server for every object access. Deny by default.
• Allow-list which fields a request may set; never spread the raw body into a database write.
• For multi-tenant systems, scope every query by tenant — consider database-level row isolation. Our SaaS platform development practice builds tenant isolation in at the data layer.
• Test with a low-privilege account, never an admin one.

Validate every input against a strict schema at the boundary — types, ranges, lengths, and allowed values. Reject what does not conform rather than trying to sanitize it. A schema validator (Zod, JSON Schema, Pydantic) at the edge of each handler closes a wide class of injection and logic bugs before they reach your data layer.

• Use parameterized queries / prepared statements everywhere — never build SQL by concatenation.
• Constrain numeric and quantity fields. A negative or absurdly large amount is a business-logic exploit waiting to happen.
• Set and verify Content-Type; reject unexpected payload formats.
• Guard against server-side request forgery: if your API fetches a URL, allow-list the destination and block internal and cloud-metadata ranges.

ATT&CK link: input flaws feed Exploit Public-Facing Application (T1190).

OWASP API4: Unrestricted Resource Consumption covers the cost-and-availability side. Without limits, one client can exhaust your capacity, run up your cloud bill, or brute-force credentials. Apply limits per authenticated identity and per IP, with tighter limits on expensive endpoints.

// Stricter limit on a sensitive endpoint
// 5 attempts / 15 min / IP on login; fail closed on limiter error
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 5,
  standardHeaders: true,       // emit RateLimit + Retry-After
  handler: (_req, res) =>
    res.status(429).json({ error: "too_many_requests" }),
});
app.post("/api/login", loginLimiter, loginHandler);

• Return 429 with a Retry-After header.
• Stricter limits on login, password reset, search, and export.
• Pair limits with per-tenant quotas so one customer cannot starve the rest.
• Bound pagination and payload sizes; reject unbounded list requests.

ATT&CK link: missing limits enable Brute Force (T1110) and Endpoint Denial of Service (T1499).

Secrets belong in a secrets manager or platform environment variables, never in source control and never in a client bundle where they are trivially extracted. This is the raw material for account takeover, so treat a leaked key as an incident.

• Store secrets in AWS Secrets Manager, GCP Secret Manager, or Vault.
• Rotate on a schedule and on any suspicion of exposure.
• Scope keys to least privilege; prefer short-lived tokens.
• Enforce TLS on every endpoint, including internal service calls.
• Verify signatures on inbound webhooks — see our Stripe webhook security guide for the pattern.

Controls decay without process. Three habits keep an API secure past launch day:

• Inventory. Maintain an up-to-date list of every endpoint and version. OWASP API9 (improper inventory management) is how forgotten staging or v1 endpoints become the breach.
• Logging and monitoring. Log authentication, authorization-denied, and high-value actions with enough context to investigate, and alert on anomalies.
• Regular testing. Re-test after any release that changes auth or data access. For compliance-driven cadence, see how to prepare for a SOC 2 audit.

For founders building payment or money-movement APIs, the stakes are higher still — our fintech penetration testing guide covers the threat model specific to APIs that touch funds, and the SaaS platform development practice builds these controls in from day one.