API security fails when authentication and authorization go granular

At a glance

What this is: This article argues that API security breaks down when teams rely on coarse signatures and treat authentication as sufficient, because modern attackers exploit granular API logic and subtle misuse patterns.

Why it matters: For IAM, PAM, and application security teams, the lesson is that API access governance must account for per-call authorisation, credential quality, and abnormal behaviour, not just login success.

Context

APIs are now a primary control surface for digital business because they connect customer applications, partners, and internal microservices while carrying sensitive data. That makes API security a governance problem as much as a detection problem, since the security model has to understand who or what is calling which function, with what level of authority, and under what normal behavioural pattern.

The weak point is not the existence of authentication alone, but the mismatch between coarse controls and highly specific API logic. When attackers can obtain legitimate credentials, abuse authorisation boundaries, or blend into expected call patterns, traditional signature-based tools lose much of their value. That is why this topic intersects directly with identity governance and API access control rather than only with perimeter defence.

The pattern described here is common in modern API estates, especially where teams have many services, user roles, and partner integrations to govern.

Key questions

Q: What breaks when API authentication is correct but authorisation is weak?

A: Attackers can still read or modify data they should not reach, because identity was proven without proving entitlement. That failure usually appears as BOLA, broken function-level access, or mass assignment. Security teams should test whether an authenticated caller can move from one object, record, or action to another without additional approval.

Q: Why do valid API requests still create breach risk?

A: Valid API requests still create breach risk because authentication proves the caller is known, not that the caller is entitled to the specific object. If the application accepts an identifier or booking code as proof of access, attackers can modify that value and harvest data without tripping traditional perimeter controls.

Q: How can security teams tell whether API risk controls are actually working?

A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why. If the control is effective, suspicious traffic should be slowed, challenged, or blocked before it reaches core systems, while legitimate integrations continue to function normally.

Q: What should security teams prioritise first in API security governance?

A: Start with the endpoints that expose sensitive data, privileged actions, or partner integrations, because those functions create the greatest breach and business impact if authorisation fails. Then layer behavioural monitoring so legitimate credentials cannot hide malicious call patterns.

Technical breakdown

Why authentication alone does not secure APIs

API authentication only answers whether a caller presents valid credentials. In modern applications, that is not enough because public-facing and developer-facing APIs often make credential acquisition easy through self-service sign-up, phishing, or reuse of legitimate accounts. Once a caller is authenticated, the attacker can probe functions, test object access, and move through application logic without ever triggering controls that only look for failed logins. This is why authentication must be tied to identity assurance, session context, and call-level policy, not treated as a stand-alone gate.

Practical implication: treat valid credentials as the start of API control, not the end of it.

How granular authorization fails in complex API estates

Authorization in APIs is difficult because every endpoint can expose different objects, roles, and business flows. As applications, partners, and microservices multiply, policy logic becomes easy to misconfigure or partially implement, especially when developers are changing features continuously. The real risk is broken or incomplete object and function authorisation, where a user is authenticated but can still request data or actions beyond their intended scope. This is why API governance has to map business functions to explicit entitlements and not rely on broad role assumptions.

Practical implication: review API authorisation at the object and function level, not only at the application boundary.

Why signature-based tools miss API abuse patterns

Web application firewalls and runtime protection tools are built to recognise known attack signatures and common abuse patterns. That approach works poorly when attackers use carefully crafted, low-volume API calls that look legitimate in isolation but are malicious in sequence or intent. The problem is behavioural, not only syntactic: a call that is technically valid can still be abnormal for the identity, application state, or expected usage pattern. Defending APIs therefore requires visibility into normal behaviour, anomaly detection, and context-aware enforcement that can distinguish legitimate automation from misuse.

Practical implication: add behavioural detection and context-aware policy to catch abuse that signatures miss.

Threat narrative

Attacker objective: The attacker wants to use valid access paths to quietly extract data or disrupt service while staying below the threshold of traditional detection.

1. Entry begins when an attacker obtains legitimate API credentials through public signup, phishing, or another low-friction authentication path.
2. Privilege abuse follows when the authenticated caller uses weak or incomplete authorisation logic to reach data or actions beyond the intended scope.
3. Impact occurs when subtle API calls drive data exfiltration, denial of service, or other business disruption without triggering signature-based controls.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API security is now an identity governance problem, not just an application security problem. Once APIs become the primary route between users, partners, and microservices, the question shifts from whether a request is authenticated to whether the caller should be allowed to perform that exact action. That brings IAM and API governance together, because access decisions now need to follow identity, context, and function. Practitioners should treat API authorisation as a governed access model, not an afterthought to login control.

Granular authorisation is where most API risk concentrates. The article’s core point is that the hard part is not proving a caller exists, but deciding whether that caller may invoke a specific object, flow, or transaction. In practice, that means broken authorisation becomes the decisive failure mode when application logic grows faster than policy management. Practitioners should map sensitive API functions to explicit entitlement boundaries and test them continuously.

API behaviour visibility is the control gap signature-based tools leave behind. WAFs and RASP-style controls struggle when abuse looks normal at the packet level but abnormal in context. That gap matters because modern attackers often do not need noisy exploitation techniques if they can blend into expected API behaviour. Practitioners should add detection that understands sequence, volume, and identity context rather than relying on static signatures alone.

Authenticated abuse is the modern API threat pattern that security teams miss too late. The governing assumption that “a valid login means a trustworthy caller” no longer holds for public and partner-facing APIs. This is especially relevant where credentials are easy to obtain or reuse and where business logic exposes high-value data or actions. Practitioners should review whether their controls are built for credential acceptance or for trustworthy function use.

OWASP API Security Top 10 remains directly relevant because the problem is structural, not isolated. The article’s concerns map to broken authentication, broken object-level authorisation, and unrestricted access to sensitive business flows. That alignment shows that API security failures are rarely about one missing control and more often about gaps between identity, authorisation, and runtime monitoring. Practitioners should use that framework to prioritise what fails first in their own estate.

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.
• Read next: API Key Management Guide

What this signals

Granular API access is becoming a governance boundary, not a technical detail. As more business processes move into APIs, the meaningful control question is whether each call is authorised for the specific identity, object, and transaction. That requires teams to think in terms of entitlement design, not just authentication coverage, especially where partners and microservices are involved.

Behavioural visibility is the named concept this market keeps missing. Static signatures cannot reliably distinguish valid API traffic from malicious use when the call itself looks normal. Practitioners should expect more emphasis on contextual detection, because API abuse increasingly happens through legitimate credentials and precise business logic rather than overt exploits.

For practitioners

• Tighten API authentication assurance Require stronger enrolment, anti-replay protections, and credential hygiene for public and partner-facing APIs so a valid login does not become the only trust signal.
• Map authorisation to API objects and functions Document which identity types may call each sensitive endpoint, then test that object-level and function-level permissions match the intended business flow.
• Add behavioural detection for API misuse Monitor request sequences, call volume, and abnormal identity context so low-and-slow abuse can be detected even when each individual call looks legitimate.
• Prioritise high-risk API flaws for remediation Focus developer effort on endpoints that expose sensitive data, privileged actions, or partner integrations where broken authorisation would create the biggest blast radius.

Key takeaways

• API security fails when organisations treat authentication as sufficient and do not govern specific API actions.
• Attackers can use valid credentials and low-noise calls to bypass tools that depend on signatures alone.
• Teams need object-level authorisation, behavioural visibility, and endpoint prioritisation to reduce API abuse risk.

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.
• Broken Function Level Authorization: A failure where an API allows a caller to invoke a function reserved for a more privileged role. The problem appears when the API checks whether a user is logged in but not whether they are allowed to perform that action. It is a privilege boundary failure at the application control layer.
• Behavioural API Detection: Behavioural API detection identifies abuse by analysing request sequences, response patterns, and session context instead of relying only on signatures. It is used to spot reconnaissance, token misuse, and data scraping that may look normal until the attacker reaches the extraction phase.
• Granular Authorization Level: A granular authorization level is a detailed view of access that examines permissions at the smallest practical unit, such as a specific entitlement or action. This level of analysis helps teams see exactly where risk exists, which roles create it, and how to target remediation more precisely.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern access control. It helps practitioners connect identity discipline to the broader security decisions their programmes depend on.