OWASP API Top 10: A 2026 Field Guide for Engineering Teams

The OWASP API Top 10 is the most widely-used checklist for API security in 2026. This guide goes through each item with concrete patterns, test approaches, and defences that actually work in production codebases.

The list at a glance

Half the list is about authorisation. That's not an accident. Most real-world API breaches are authorisation failures.

API1: Broken Object Level Authorization (BOLA)

The single most common API vulnerability. The endpoint receives an object ID, the user is authenticated, but the API doesn't check that this user owns this object.

The pattern that's wrong:

GET /api/invoices/:id
  → fetch invoice by id
  → return it

Any authenticated user can read any invoice if they guess the ID.

The fix:

GET /api/invoices/:id
  → fetch invoice by id
  → check invoice.userId === currentUser.id (or org membership)
  → return it, or 404

Test by signing in as user A and trying to access user B's resources. Every endpoint, every resource type.

API2: Broken Authentication

The endpoint accepts a token but doesn't validate it properly. Common variants:

• JWT signature not verified.
• JWT verified but expiry not checked.
• Refresh tokens with no rotation.
• "Forgot password" flow that doesn't invalidate old sessions.

Defences:

• Use a battle-tested library for JWT verification. Never roll your own.
• Always check expiry, issuer, and audience.
• Rotate refresh tokens on every use.
• Invalidate all sessions on password change.

API3: Broken Object Property Level Authorization

The endpoint correctly enforces "you can see this object", but lets the user update properties they shouldn't.

Pattern that's wrong:

PATCH /api/users/me
  → accept any field from the request body
  → write it

A user PATCHes their own user record and sets isAdmin: true.

The fix: allow-list the properties a user can modify on themselves. Reject everything else.

API4: Unrestricted Resource Consumption

No rate limit. No request size cap. No timeout. An attacker can drive cost or trigger denial-of-service by hammering an expensive endpoint.

Defences:

• Rate limit per user, per IP, per endpoint.
• Body size limits in your reverse proxy or framework.
• Query timeouts on database operations.
• Cost limits on expensive endpoints (image processing, AI inference, large reports).

API5: Broken Function Level Authorization

The user can call an admin endpoint by knowing the path. Authorisation is checked in the UI but not on the server.

Every endpoint must verify the caller has the right role server-side. Never trust the UI.

API6: Unrestricted Access to Sensitive Business Flows

Specific flows in your product are sensitive: account creation, password reset, payment, refund. If they're not protected from automated abuse, they get abused.

Defences:

• Anti-automation on sign-up: CAPTCHA, device fingerprint, rate limit.
• Step-up authentication on payment changes.
• Cooling-off periods on bulk actions.
• Audit log on every sensitive action.

API7: Server Side Request Forgery (SSRF)

Your API accepts a URL from the user, fetches it, and returns the content. Attacker passes an internal URL and your server makes the request from inside the network.

Defences:

• Allow-list of domains for any user-supplied URL.
• Block internal IP ranges (RFC1918, 169.254.0.0/16, localhost).
• Use a dedicated SSRF-safe HTTP client library.
• Don't echo response bodies back to the user unless you must.

API8: Security Misconfiguration

The catch-all. Insecure defaults, exposed admin panels, default credentials, verbose error messages, missing security headers.

Concrete defences for 2026:

• HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options.
• No stack traces in production error responses.
• Default deny on cloud security groups.
• Secrets not committed to git (use a scanner like Gitleaks in CI).

API9: Improper Inventory Management

You have old API versions still serving traffic, but no one is patching them. The new version is hardened. The old version is the one that gets exploited.

Defences:

• Inventory every API endpoint, every version. Keep a list.
• Deprecation policy with a sunset date.
• Block calls to deprecated versions in your gateway after the sunset.
• Same security testing on every version that's still live.

API10: Unsafe Consumption of APIs

You call third-party APIs. You trust their responses. An attacker compromises the third party. Your product is now compromised through transitive trust.

Defences:

• Validate response shape and types, never trust shape.
• Sanitize anything you display from a third-party API.
• Use mTLS or signed requests for high-value third-party calls.
• Monitor third-party APIs for status and integrity.

How to test for these

A practical testing approach:

• Automated SAST. Semgrep, GitHub CodeQL, SonarQube. Runs on every PR. Catches the static issues: unsafe deserialization, hard-coded secrets, missing input validation.
• Dependency scanning. Snyk, Trivy, Dependabot. Catches vulnerable libraries.
• Manual code review focused on authorisation. Every PR that touches an endpoint, ask: "what stops user B from accessing user A's data here?"
• Quarterly internal pen test. A team member spends a day specifically trying to BOLA themselves.
• Annual external pen test. Adds an outside perspective and is usually required for SOC 2 anyway.

Common mistakes

• Treating authorisation as a one-time review. New endpoints get added every sprint. Each one is a new BOLA opportunity.
• Relying on the UI for authorisation. The UI hides things. The API has to enforce them.
• Verbose error messages in production. They leak schema, file paths, version info.
• No API inventory. You can't secure what you don't know exists.

How Hashorn helps with API security

Hashorn provides security engineering for SaaS, fintech, and Web3 teams. We implement the OWASP API Top 10 controls into your SDLC, set up CI scanners, and run quarterly authorisation reviews. We pair this with DevOps and CI/CD so the security controls are part of the pipeline, not bolted on.

Conclusion

The OWASP API Top 10 in 2026 is mostly about authorisation. If your team gets BOLA and broken function-level authorisation right, you've removed the majority of the real-world breach surface. Layer on the resource limits, the inventory hygiene, and the misconfiguration audits, and you're in the top quartile of API security maturity for your size.