API security vulnerabilities are still exposing access control gaps

At a glance

What this is: This is an analysis of common API security vulnerabilities found in Pynt’s internal testing data, with missing authentication, injection flaws, BOLA, and flawed JWT validation emerging as the main patterns.

Why it matters: It matters because API failures often expose identity and authorisation controls, which is where IAM, PAM, application security, and fraud-prevention concerns start to overlap.

By the numbers:

• Pynt identified 900 cases of missing authentication across real APIs tested in development.
• 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.
• Pynt identified approximately 140 instances of flawed JWT validations in tested APIs.

👉 Read Pynt's analysis of common API security vulnerabilities in development

Context

API security is really an access-control problem as much as it is a software testing problem. When authentication is missing or object-level authorisation is weak, APIs become direct paths to data exposure, unauthorised actions, and downstream identity abuse. The primary issue is not that APIs are new, but that they often inherit trust assumptions that are too broad for modern distributed systems.

Pynt’s analysis reflects a common enterprise reality: developers and security teams often discover these weaknesses late, after code paths and token logic are already embedded in build pipelines. That makes shift-left testing relevant not only to application security, but also to identity governance, because API auth failures frequently determine who or what can act on behalf of a user or service. For readers who want a broader NHI view of secret and token exposure, the Ultimate Guide to NHIs , Key Challenges and Risks is a useful companion.

The most relevant starting point for object-level access failures is the Schneider Electric credentials breach, where exposed credentials enabled access to internal systems. For a wider pattern of secret exposure and code-path risk, the CI/CD pipeline exploitation case study shows how early development weaknesses can become production-grade compromise.

Key questions

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. Discovery alone is not enough. The control must be embedded in testing, CI checks, and ownership workflows so any endpoint without required authentication fails promotion before it can be deployed.

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. Developers often assume the session is enough. In distributed systems, that assumption breaks quickly unless every object access is authorised on the server side.

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. If any of those tokens are accepted, the validation model is not trustworthy. Validation must be consistent across services, not just correct in one gateway or library.

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.

Technical breakdown

Missing authentication in APIs

Missing authentication means an API endpoint accepts requests without reliably verifying the caller’s identity. In practice, that can happen through forgotten admin routes, misconfigured gateway rules, or endpoints exposed during development and never re-locked. The control failure is simple but severe: if the service cannot distinguish an authorised caller from an unauthorised one, every downstream object or action remains exposed. This is often less about sophisticated exploitation and more about incomplete lifecycle controls around the API surface. Practical implication: security teams need inventory-driven authentication coverage tests that fail builds when any reachable endpoint lacks enforced auth.

Practical implication: security teams need inventory-driven authentication coverage tests that fail builds when any reachable endpoint lacks enforced auth.

BOLA and object-level authorisation

Broken Object Level Authorization, or BOLA, occurs when an API authenticates the caller but fails to verify whether that caller may access a specific object, record, or tenant boundary. This is especially dangerous in multi-tenant systems, where changing an identifier in a request can reveal another user’s data if the authorisation check is missing or inconsistent. BOLA is not an authentication problem alone. It is a trust-boundary failure at the object layer, where identity is accepted but entitlement is not re-checked. Practical implication: every object lookup must be paired with server-side authorisation logic, not client-provided assumptions.

Practical implication: every object lookup must be paired with server-side authorisation logic, not client-provided assumptions.

JWT validation and token trust

JWT validation failures usually involve weak signature checks, incorrect issuer or audience validation, or acceptance of expired or tampered tokens. Because JWTs often carry identity claims and authorisation context, a bad validation path can let attackers impersonate users or escalate actions without needing passwords. This matters in identity programmes because token trust becomes a control plane decision, not just a developer convenience. In federated systems, a token that is structurally valid but contextually wrong can still pass through multiple services before anyone notices. Practical implication: token validation must be centrally tested against issuer, audience, expiry, and signature requirements across all services.

Practical implication: token validation must be centrally tested against issuer, audience, expiry, and signature requirements across all services.

Threat narrative

Attacker objective: The attacker’s objective is to gain unauthorised access to data or actions through API trust failures, then use that access to read, modify, or abuse sensitive resources.

1. Entry occurs through exposed or weakly protected API endpoints that accept unauthenticated or insufficiently validated requests.
2. Escalation follows when attackers exploit BOLA or flawed JWT validation to move from basic request access to unauthorised object access or impersonation.
3. Impact is unauthorised data exposure, account misuse, or system actions performed on behalf of legitimate users or services.

NHI Mgmt Group analysis

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.

Shift-left testing only works when it is tied to a lifecycle control model. Finding flaws at the developer desk is useful, but it only changes outcomes if unresolved endpoints cannot advance into release. The field needs a stronger link between API testing results, CI/CD gatekeeping, and remediation ownership. Otherwise, teams get better visibility without materially reducing exposure.

Object-level failure is the named concept practitioners should watch for: API trust leakage. This is the gap between authenticating a caller and proving that the caller can act on a specific object, tenant, or token scope. It is a subtle but recurring failure mode in modern distributed systems, especially where service-to-service trust is inherited rather than verified. The practitioner conclusion is clear: authorisation must be enforced at the object, not assumed at the session.

JWT validation should be treated as a distributed trust boundary. Once tokens are accepted across multiple services, validation errors can propagate rapidly and become hard to isolate. That is why token handling belongs in governance discussions alongside identity verification, secrets management, and service-to-service authentication. Teams should assume that one weak verifier can undermine many downstream controls.

The control gap here is not lack of tools, but lack of end-to-end enforcement. Pynt’s findings reflect a broader market reality: many organisations can detect API flaws, yet still fail to ensure that auth, authorisation, and token logic are consistently enforced before deployment. The result is a testing signal without a governance outcome. Practitioners should align API scanning with release criteria, ownership, and exception handling.

What this signals

API auth failures are now part of the identity control surface. As more services depend on bearer tokens, session claims, and delegated access, API testing must be aligned with IAM ownership and release governance. Teams that treat these findings as development-only issues will keep rediscovering the same risk in production.

OAuth-connected services and API tokens create a broad trust fabric that is hard to observe end to end. That is why the governance challenge is not only finding bad endpoints, but proving that identities, tokens, and object permissions are consistently constrained across the application lifecycle. For teams working from an identity lens, the Ultimate Guide to NHIs , Key Challenges and Risks remains a useful reference point.

The practical shift is toward treating API security findings as policy decisions. If an endpoint or token path cannot be explained in entitlement terms, it should not be promoted into a production trust boundary.

For practitioners

• Enforce endpoint-level authentication coverage Map every reachable API endpoint, then block release if any path lacks server-side authentication. Include admin, debug, and internal endpoints in the same inventory so unauthenticated access cannot slip through because the route is assumed to be low risk.
• 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. This is the most direct way to catch BOLA before deployment, and it should be tied to a failing build.
• Centralise JWT verification rules Standardise issuer, audience, expiry, signature, and algorithm validation across services, then prove those checks in automated tests. Token trust should not vary by team or microservice, because inconsistent validation creates invisible privilege paths.
• Gate promotion on unresolved API findings Require remediation or formal exception approval before vulnerable endpoints can move from development into staging or production. Shift-left only reduces risk when the pipeline has authority to stop insecure code, not just report it.

Key takeaways

• API security flaws often reveal identity and authorisation failures rather than isolated coding mistakes.
• Pynt’s analysis found 900 missing-authentication cases, 300 injection issues, 200 BOLA instances, and 140 flawed JWT validations across real APIs.
• The most effective response is to tie API testing to release gates, object-level authorisation, and central token validation.

Key terms

• BOLA: Broken Object Level Authorization occurs when an application fails to verify that a user is permitted to act on a specific object. It is closely related to IDOR, but the core issue is authorisation logic, not the visible object reference itself.
• JWT Validation: JWT validation is the process of checking that a token is signed correctly and that its claims match what the application expects. For OIDC, that means verifying issuer, audience, and expiration, not just decoding the token and trusting its contents.
• Shift-left security: Shift-left security means moving security checks and remediation earlier in the software delivery lifecycle, especially into development and pull request workflows. The goal is to surface issues when they are cheapest to fix and closest to the code change that introduced them.

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.

👉 The full Pynt post includes the vulnerability breakdown, remediation rationale, and shift-left testing context.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to connect access governance to the broader security programme.