Notifications
Clear all
Topic starter
19/08/2026 3:47 pm
TL;DR: Real API tests found 900 cases of missing authentication, 300 injection issues, 200 BOLA instances, and 140 flawed JWT validations, showing that basic access control and input handling failures still dominate API risk, according to Pynt. Shift-left testing matters because these weaknesses become far more expensive once they reach production.
NHIMG editorial — based on content published by Pynt: common API security vulnerabilities identified through internal analysis
By the numbers:
- Pynt found around 300 instances of injection vulnerabilities, including command injection, SQL injection, and NoSQL injection.
- Pynt discovered over 200 unique instances of BOLA vulnerabilities in its analysis of real APIs.
Questions worth separating out
Q: How should teams prevent unauthenticated API endpoints from reaching production?
A: Teams should inventory all reachable endpoints, including internal and administrative paths, then enforce server-side authentication as a release gate.
Q: Why does BOLA remain such a common API security failure?
A: BOLA persists because many systems authenticate the caller but do not re-check whether that caller may access a specific object, record, or tenant boundary.
Q: How do security teams know whether JWT validation is actually working?
A: They should test the full token lifecycle, including expired tokens, altered signatures, wrong issuers, wrong audiences, and algorithm confusion cases.
Practitioner guidance
- Enforce endpoint-level authentication coverage Map every reachable API endpoint, then block release if any path lacks server-side authentication.
- Add object-level authorisation tests to CI Test that each object lookup, tenant selector, and resource identifier is checked against the authenticated principal before response generation.
- Centralise JWT verification rules Standardise issuer, audience, expiry, signature, and algorithm validation across services, then prove those checks in automated tests.
What's in the full article
Pynt's full blog post covers the operational detail this post intentionally leaves for the source:
- The full breakdown of how the 900 missing-authentication cases were identified across real development APIs.
- The vendor's deeper examples of injection, BOLA, and JWT validation patterns across tested applications.
- The internal analysis behind why these flaws persist even when teams believe security testing is already in place.
- The practical developer-workflow context for shifting API security testing left without slowing releases.
👉 Read Pynt's analysis of common API security vulnerabilities in development →
API security vulnerabilities: are your authentication checks failing early?
Explore further
19/08/2026 4:24 pm
API security is increasingly an identity governance problem, not just an application testing problem. Missing authentication and BOLA show that many API failures are really failures to govern who or what is allowed to act on a resource. That makes identity context, token trust, and object-level entitlement checks central to the control model. Practitioners should treat API security as part of access governance, not as a separate checklist.
A question worth separating out:
Q: What should organisations do when API testing finds missing authentication or BOLA?
A: Treat the finding as a release-blocking governance issue, not a code comment. Assign ownership to the service team, require remediation or exception approval, and confirm the fix with a repeat test. If the endpoint touches identity claims or sensitive data, prioritise it above cosmetic defects because the business impact is immediate.
👉 Read our full editorial: API security vulnerabilities are still exposing access control gaps
