API Security Beyond JWT: The Threats Nobody Is Patching

We run security audits for startups and mid-size companies. The first question every client asks is "We use JWT authentication, so our API is secure, right?" The answer is always the same: JWT handles identity. It does not handle authorization, rate limiting, input validation, data exposure, or any of the other attack surfaces that actually get exploited in production.

Here are the nine API security issues we find in nearly every audit, ranked by frequency.

Broken Object-Level Authorization (BOLA): found in seventy percent of audits. User requests GET /api/orders/123, gets their order. Changes to /api/orders/124, gets someone else's order. The JWT is valid but the API never checks resource ownership. Fix: middleware that verifies ownership before every handler executes.

Mass assignment: the API passes JSON bodies directly to database updates. A user sends an extra field like role: "admin" and the API blindly writes it. Found in sixty percent of audits. Fix: Zod schemas that validate and strip unexpected fields from every write endpoint.

Excessive data exposure: API returns full database records including password hashes, internal notes, or billing details alongside public data. Fix: explicit response schemas that map database records to API responses, never returning raw database objects.

Missing rate limiting: without it, attackers can brute force authentication, enumerate resources, or mount denial of service attacks. Every public endpoint needs rate limiting, and auth endpoints need aggressive limiting.

SQL injection via dynamic queries: not in the raw form, but in dynamic filter and sort parameters. An API accepting sort_by=name as a query parameter and interpolating it into an ORDER BY clause without validation is vulnerable.

Insecure file access: path traversal where /api/files/../../etc/passwd exposes server files. Even with cloud storage, path traversal in S3 key construction can expose other users' files.

Missing validation on nested objects: top-level fields validated, but nested objects and arrays passed through unchecked, creating stored XSS vulnerabilities when displayed in admin dashboards.

Verbose error messages: stack traces, database query errors, and internal paths in production responses. Each error message is a roadmap for attackers.

Misconfigured CORS: wildcard Access-Control-Allow-Origin or reflecting the request origin without validation allows any website to make authenticated requests to your API.

Our security checklist has twenty-three items. We run through it at the start of every project and again before launch. The investment is one to two days of engineering time. The alternative is a breach notification email to your users, which costs significantly more.