API attack surface growth is outpacing authentication controls

At a glance

What this is: This is a practical guide to API security that frames the API attack surface as the collection of exposed endpoints, weak controls, and infrastructure gaps attackers can exploit.

Why it matters: It matters because API attack surface management depends on identity controls, authorization quality, token handling, and monitoring, all of which directly affect IAM, PAM, and secrets governance.

By the numbers:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and a further 47% have only partial visibility.

👉 Read StackHawk's guide to discovering and securing your API attack surface

Context

API attack surface is the total set of reachable API endpoints, parameters, credentials, and supporting infrastructure that can be abused if controls are weak. In modern applications, that surface grows quickly because APIs connect mobile apps, web apps, partner integrations, and internal services, which makes identity and authorization quality central to security.

The identity angle is real even in a broad AppSec article. Authentication, authorization, token handling, role design, and secret management determine whether an API behaves like a controlled interface or an open trust boundary. Shadow APIs and undocumented versions create the same governance problem that unmanaged identities do in other environments: you cannot secure what you cannot inventory.

Key questions

Q: How should security teams reduce API attack surface without slowing delivery?

A: Start by making API discovery part of the release process, then test authorization at the object and function level before every deployment. Pair that with gateway enforcement, token lifecycle management, and runtime monitoring so new endpoints do not become unmanaged trust paths. Delivery stays fast when the control set is automated and owned across engineering and security.

Q: Why do APIs create identity risk even when the application code is secure?

A: APIs create identity risk because the code can be clean while the credentials behind it remain exposed, over-privileged, or reused. Attackers usually target the secret, not the endpoint. Once they have a valid key or token, they can impersonate the workload and inherit whatever access that identity already has.

Q: What breaks when endpoint inventory is incomplete?

A: When endpoint inventory is incomplete, patching, configuration enforcement, and access restrictions all become partial controls. Unseen devices cannot be updated, monitored, or quarantined reliably, so attackers and unmanaged devices gain a path into the environment. The control failure is not just visibility, but unenforced policy.

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.

Technical breakdown

Why API attack surfaces expand faster than security reviews

An API attack surface grows whenever teams add new endpoints, versions, parameters, integrations, or supporting services faster than they can inventory them. That expansion creates blind spots around undocumented APIs, stale routes, and forgotten test systems. Because APIs are often consumed machine to machine, control failure is usually not about user behaviour but about missing enforcement at the interface layer. The result is a broader trust boundary than most teams realise, especially when development, operations, and security each own only part of the lifecycle.

Practical implication: treat API discovery as a governance control, not a one-time scan.

How authentication and authorization flaws turn APIs into access multipliers

Authentication proves who or what is calling an API, while authorization decides what that caller may do. Weak passwords, broken tokens, flawed role mappings, and missing object-level checks all allow attackers to move from a single valid session into broader data access or function abuse. In practice, broken object level authorization and broken function level authorization are especially dangerous because they let attackers query or modify records they were never meant to reach. This is where API security intersects directly with IAM and PAM discipline.

Practical implication: pair API testing with privilege design and object-level access review.

Why API inventory and runtime monitoring must work together

Inventory alone tells you what exists, but not whether it is being abused. Runtime monitoring adds evidence of unusual request patterns, excessive calls, unauthorized method use, and suspicious token behaviour. That distinction matters because many API attacks exploit valid credentials or legitimate endpoints rather than obvious malware. Security teams need both sides of the picture to distinguish normal service-to-service traffic from abuse, data scraping, or privilege misuse. Without that combination, teams end up finding exposures only after data has moved.

Practical implication: correlate API discovery data with runtime logs and auth events.

Threat narrative

Attacker objective: The attacker wants to use a small API weakness to gain broad data access, manipulate application behaviour, or interrupt critical services.

1. Entry occurs through exposed or undocumented API endpoints, weak authentication, or stale versions that remain reachable after deployment.
2. Escalation happens when broken object-level or function-level authorization lets the attacker use a valid call path to reach records, methods, or business flows outside intended scope.
3. Impact follows through data exposure, service disruption, or abuse of sensitive API functions that the application trust model failed to restrict.

NHI Mgmt Group analysis

API attack surface management is becoming an identity governance problem, not just an AppSec task. The article is strongest when it shows that APIs are defined by reachable functions and the controls surrounding them, not just by code quality. Once authentication, authorization, and token handling sit at the center of risk, API inventory becomes a governance issue as much as a technical one. Practitioners should align AppSec discovery with IAM ownership and access review.

Broken object and function authorization are the API equivalent of over-privileged access. They let a caller do more than its intended scope, which is exactly the governance failure identity teams try to prevent in human and non-human programmes. This is why API security and NHI control design increasingly converge around least privilege, scope limitation, and continuous validation. Practitioners should treat authorization testing as a privilege-control exercise, not just a vulnerability check.

Undocumented APIs create a shadow access problem that looks familiar to NHI sprawl. When teams do not know which interfaces exist, they also do not know which credentials, tokens, or service accounts can reach them. That mirrors the inventory gap in non-human identity programmes, where unused or forgotten access remains active longer than intended. Practitioners should connect API discovery to identity lifecycle controls so hidden endpoints do not become hidden trust paths.

API security failures often reflect a missing control boundary between development and runtime enforcement. The article makes clear that static code review, DAST, gateways, and rate limiting all solve different parts of the problem. No single layer closes an API attack surface that changes every time a service version or integration changes. Practitioners should build API governance across the pipeline and the runtime, not inside a single team.

Attack surface visibility is the named concept this article points to most clearly. The practical issue is not whether APIs are secure in theory, but whether teams can continuously see endpoints, versions, methods, and auth paths that attackers can reach. Once visibility breaks, prioritisation breaks with it. Practitioners should use the concept of attack surface visibility as the bridge between security testing and access governance.

What this signals

API attack surface work is converging with identity governance because the same failure pattern shows up in both areas: reachable capability outpaces control visibility. When teams cannot see endpoints, owners, tokens, and permissions together, they cannot prove least privilege or support trustworthy incident response. A useful framing here is attack surface visibility debt: the accumulation of undocumented interfaces and mismatched ownership that turns routine change into security drift.

For practitioners, the signal is that API security metrics should no longer stop at vulnerability counts. Teams need evidence that every API has an owner, every token has a lifecycle, and every access path is tested for object-level and function-level abuse. That is where API programmes start to resemble IAM and NHI governance, especially when service credentials and OAuth tokens are part of the path.

The governance next step is to connect discovery, authorization testing, and runtime telemetry into one control view using standards such as the NIST SP 800-53 Rev 5 Security and Privacy Controls and the MITRE ATT&CK Enterprise Matrix. If those views are separate, the organization will know it has APIs, but not whether those APIs are safe to trust.

For practitioners

• Inventory all exposed and shadow APIs Scan code repositories, runtime traffic, and gateways to identify undocumented endpoints, stale versions, and test services that still respond to requests. Map each API to an owning team and an explicit business purpose before you allow it to remain reachable.
• Test object-level and function-level authorization continuously Add negative tests for object identifiers, HTTP methods, and business functions so a caller cannot access records or actions outside its intended scope. Focus on broken object level authorization and broken function level authorization, because those failures turn valid sessions into privilege escalation paths.
• Tie API tokens and service credentials to lifecycle controls Register API keys, OAuth tokens, and service account credentials in the same lifecycle process you use for other non-human identities. Rotate secrets, revoke stale tokens, and confirm that offboarding removes access from old integrations and abandoned environments.
• Correlate discovery data with runtime abuse signals Combine API inventory with logs for unusual request volume, method misuse, and repeated authorization failures. This helps you separate normal machine-to-machine traffic from scraping, enumeration, and abuse that are otherwise easy to miss.

Key takeaways

• API attack surface is a governance problem as much as a technical one because hidden endpoints and weak ownership create unseen trust paths.
• Broken object-level and function-level authorization are the controls most likely to turn a valid API call into broad unauthorized access.
• Teams need discovery, authorization testing, and runtime monitoring together, or API security will remain incomplete in practice.

Key terms

• API Authentication Surface: The API authentication surface is the set of login, token, and session endpoints that establish identity for an application. It is where identity governance becomes operational, because attackers can abuse the same endpoints that legitimate users and services rely on for access.
• 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.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.

What's in the full article

StackHawk's full blog post covers the operational detail this post intentionally leaves for the source:

• API discovery workflow details for finding hidden and undocumented endpoints in code and runtime traffic
• Step-by-step DAST coverage for REST, SOAP, RPC, and GraphQL APIs across the pipeline
• Specific authentication and authorization hardening patterns for JWT, OAuth 2.0, and RBAC
• Gateway and rate-limiting implementation guidance for reducing abuse and service disruption

👉 StackHawk's full post covers API discovery, authorization weaknesses, and practical hardening measures

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is a fit for practitioners who need to connect access governance to the broader security programme.