API security vulnerabilities are still exposing access control gaps

At a glance

What this is: Pynt reports that real API testing still surfaces large volumes of missing authentication, BOLA, injection, and flawed JWT validation issues.

Why it matters: For IAM and application security teams, the finding shows that API access control and token validation failures remain basic governance gaps, not edge cases, and they need to be tested before code reaches production.

By the numbers:

• Pynt’s analysis found 900 cases of missing authentication in real API tests.
• Pynt’s analysis found 300 instances of injection vulnerabilities in real API tests.
• Pynt’s analysis found over 200 unique instances of BOLA vulnerabilities in real API tests.
• Pynt’s analysis found approximately 140 instances of flawed JWT validations in real API tests.

Context

APIs now sit on the control path for most modern applications, which makes API authentication and authorisation failures a direct governance issue rather than a narrow engineering defect. When those controls are missing or inconsistent, attackers can reach sensitive functions and data without ever needing to defeat stronger perimeter controls.

The article is also a reminder that the value of API security testing is in finding access-control weaknesses before release. For teams responsible for IAM, application security, and secrets governance, the key question is whether authentication checks, token validation, and object-level authorisation are being verified early enough to prevent production exposure.

Key questions

Q: What breaks when an API endpoint does not require authentication?

A: When an API endpoint does not require authentication, every control that depends on knowing the caller becomes unreliable. Roles, ACLs, and session policies only work after identity is established, so an open endpoint bypasses the access hierarchy rather than merely weakening it. In practice, the flaw turns a platform into a publicly reachable data path.

Q: Why do business logic flaws and broken object-level authorization create so much access risk in APIs?

A: They let requests succeed even when the application should enforce tenant separation or object ownership. That means an attacker can reach data or actions outside their authority, often by chaining legitimate-looking requests. These flaws are dangerous because conventional testing can miss multi-step abuse paths, especially where access control depends on request sequence rather than a single check.

Q: How do teams know if API security testing is actually effective?

A: Look for coverage of realistic workflows, successful reuse of returned values, and findings that map to business operations instead of only parameter errors. If a tool cannot move from one response to the next with meaningful context, it is probably testing syntax, not logic.

Q: What is the difference between authentication and authorisation in REST API security?

A: Authentication verifies who is calling the API, while authorisation determines what that caller is allowed to do. An API can authenticate a user or service and still be insecure if permissions are too broad. Strong REST API security needs both, because identity proof alone does not prevent overexposure, privilege abuse, or access to resources beyond the intended scope.

Technical breakdown

Missing authentication at the API boundary

Missing authentication means the API accepts requests without first proving the caller is allowed to act. In practice, this creates an open control surface where any client can reach protected functions if the route is exposed. The article’s finding matters because authentication is not a cosmetic layer, it is the gate that determines whether the API is public, internal, or restricted. When that gate is absent, downstream controls such as logging or rate limiting cannot recover the trust failure.

Practical implication: verify that every API route has an explicit authentication requirement before it is merged or deployed.

BOLA and object-level authorisation failures

Broken Object Level Authorisation happens when the API authenticates a user but fails to check whether that user owns or may access the specific object requested. This is one of the most common ways APIs leak data because the request is valid in form but invalid in scope. The problem is usually not password strength or session quality, but missing per-object access checks on IDs, account records, orders, or other resources. That makes BOLA a direct authorisation design failure, not just a bug.

Practical implication: test every object reference and ID path for authorisation, not just the login flow.

JWT validation and trust in self-contained tokens

Flawed JWT validation occurs when an API accepts a token without fully checking signature integrity, issuer, audience, expiry, or algorithm constraints. Because JWTs are self-contained, a validation mistake can let an attacker reuse, tamper with, or forge claims that the application then trusts. The security issue is not the token format itself but the assumption that the token proves more than it actually does. In mature API design, token validation is part of the trust boundary, not a convenience check after authentication.

Practical implication: validate JWTs against strict issuer, audience, signature, and expiry rules in every protected service.

NHI Mgmt Group analysis

API access control failures remain a first-order governance problem: missing authentication and BOLA are not advanced attack chains, they are basic boundary failures that let attackers use legitimate request paths to reach data they should never see. That is why API security belongs in the same control conversation as IAM, not only application testing. Organisations that treat API checks as late-stage QA will keep discovering the same authorisation gaps too late. Practitioners should govern API access as a core identity and application control.

Shift-left API testing is now an exposure-reduction control, not just a developer convenience: the article’s counts show that common weaknesses are still being found in development, which is exactly where they should be caught. Once these issues reach production, the blast radius expands from a single broken endpoint to an environment-wide data exposure risk. The concept here is early boundary assurance, meaning controls must verify authentication and authorisation before release. Practitioners should embed that assurance into CI and pre-production review.

JWT validation errors expose a trust model problem, not merely a token problem: if services accept weakly validated self-contained tokens, they are outsourcing trust to claims that may never have been properly checked. That matters for both human and non-human access patterns, because the same token trust failure can authorise users, service calls, and automation flows. In other words, token validation is part of identity governance at the API layer. Practitioners should treat JWT rules as enforceable policy, not optional framework guidance.

API security and identity governance are converging around the same failure modes: object-level authorisation, missing authentication, and token validation all describe how access decisions fail at the edge of a service. That is why API security metrics should be reported alongside IAM and PAM exposure, especially where APIs expose customer data or privileged actions. The field is moving toward continuous access verification across code, tokens, and runtime requests. Practitioners should align API testing with identity controls rather than managing it as an isolated AppSec activity.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: API Key Management Guide

What this signals

Early boundary assurance: API security testing has to move into build and release gates because missing authentication and object-level authorisation errors are control failures, not post-production tuning problems. The practical effect for programme owners is that API risk should be measured at commit and deployment time, where access rules are still cheap to change.

For identity and application teams, API authorisation is increasingly part of the same governance surface as service accounts, tokens, and delegated access. If token validation is weak or object-level checks are inconsistent, the organisation has an identity problem embedded in its API layer, which makes access review and policy enforcement a shared concern.

For practitioners

• Enforce authentication on every API route Create a route-level inventory and block releases where any externally reachable endpoint lacks an explicit authentication requirement. Include service-to-service APIs and admin functions, not just customer-facing paths.
• Test object-level authorisation for every identifier Probe each endpoint with altered object IDs, account numbers, and resource handles to confirm the API checks ownership and entitlement per request. Focus on APIs that expose records, orders, or privileged actions.
• Validate JWTs against strict trust rules Require signature, issuer, audience, expiry, and allowed-algorithm checks in every protected service, and reject tokens that pass parsing but fail policy. Include shared libraries in the review so weak defaults do not spread across teams.
• Shift API security testing into pre-production gates Run automated API security checks in CI and before deployment so missing authentication, BOLA, injection, and token validation failures are found at the developer desk rather than in production.

Key takeaways

• API vulnerabilities in this analysis are dominated by basic trust failures, especially missing authentication, BOLA, injection, and flawed JWT validation.
• The article’s figures show that these issues are not rare edge cases, with missing authentication the most common finding and BOLA also appearing repeatedly across real tests.
• The control lesson is to verify authentication and authorisation before production, because API boundary failures become materially harder to contain once exposed to live traffic.

Key terms

• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• 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 API Security: Shift-left API security moves testing and governance earlier in the software delivery lifecycle, before code reaches production. It uses discovery, documentation, and security testing during development, build, integration, and QA to catch authentication, authorization, and schema problems when remediation is faster and less disruptive.
• Authorization Gap: The distance between what an authenticated identity can do and what it is actually permitted and proven to do in real time. For AI agents, the gap widens when decisions are made per action, at machine speed, and through workflows that expand faster than human review cycles.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to API, service, and automation risks.