TL;DR: 68% of organisations do not have complete visibility into their API attack surface, while AI-accelerated development is creating APIs faster than security teams can catalog them, leaving shadow APIs and runtime abuse exposed, according to StackHawk’s 2026 AppSec survey. The core issue is governance lag: discovery, testing, and ownership models are still built for slower software cycles.
At a glance
What this is: StackHawk argues that API security failures are increasingly rooted in visibility gaps, with shadow APIs and fast-moving development outpacing cataloguing and testing.
Why it matters: For IAM and security teams, API inventory gaps mean authentication, authorisation, and runtime controls may only cover known assets, leaving ungoverned interfaces exposed to abuse.
By the numbers:
- 68% of organizations admit they do not have complete visibility into their API attack surface.
Context
API attack surface visibility is the control problem underneath modern API security. When teams cannot reliably discover, classify, and own every API, testing and monitoring only protect the interfaces that were already documented, while shadow APIs remain outside governance.
This is not just an application security problem. API exposure now intersects with identity and access management because broken authentication, overbroad authorisation, and uncontrolled machine-to-machine access often become the practical failure points once an API is reachable.
In fast-moving delivery environments, the gap between what exists and what security can see is now a governance issue rather than a tooling inconvenience. That pattern is already typical in API-first organisations and is widening as AI-assisted development increases release velocity.
Key questions
Q: What breaks when an organisation cannot see its full API attack surface?
A: Teams lose control over discovery, ownership, and testing scope, which means shadow APIs can remain reachable without formal authentication review or remediation. The result is not just missing inventory. It is partial governance, where security controls apply only to the interfaces the organisation already remembers to track.
Q: Why do undocumented APIs increase exposure even when authentication is in place?
A: Authentication only confirms that a caller has some recognised identity or credential. If the endpoint itself is unmanaged, downstream authorisation, response filtering, and data handling may never have been validated, so valid access can still produce unintended disclosure or business logic abuse.
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: Should teams prioritise shift-left testing or runtime API monitoring first?
A: They should do both, but runtime monitoring becomes the deciding control once APIs reach production. Shift-left testing reduces defects before release, while runtime visibility catches drift, abuse, and access violations that only appear under live traffic.
Technical breakdown
Why API discovery fails in modern development pipelines
API discovery fails when inventory depends on documentation, quarterly reviews, or network-only scanning. REST, GraphQL, gRPC, and SOAP endpoints can be created inside microservices, serverless functions, and ephemeral environments faster than security can register them. Source code, traffic analysis, and authenticated testing each expose different parts of the surface, which is why no single passive method gives full coverage. The central problem is that an API may exist, accept traffic, and process credentials long before anyone has formally assigned ownership or testing scope.
Practical implication: discovery has to move closer to source code and deployment pipelines, or undocumented APIs will stay outside control.
How visibility gaps turn into broken authentication and business logic abuse
Once an API is reachable but poorly governed, attackers do not need exotic techniques. Broken authentication lets them impersonate users or services, while business logic abuse uses valid requests in unintended sequences to move data or money in ways the API was never meant to permit. Runtime visibility matters because many of these issues only appear under real traffic patterns, not in static review. For identity teams, the key point is that API trust is enforced at issuance, authentication, and authorisation time, not after the request has already executed.
Practical implication: authentication and authorisation checks must be validated against live API behaviour, not assumed from design documentation.
Why API security now depends on lifecycle governance, not point-in-time testing
API security has shifted from a scan-and-fix exercise to a lifecycle governance problem. Continuous integration pipelines, production traffic, and compliance evidence now need to line up so teams can prove that discovery, testing, and remediation are recurring controls rather than one-off events. That is especially important where API access underpins machine identities, service accounts, and delegated third-party integrations. The organisation that cannot track an API from creation to retirement cannot credibly claim it controls the access paths exposed through that API.
Practical implication: treat API inventory, testing, and retirement as one governed lifecycle, or compliance evidence will remain incomplete.
NHI Mgmt Group analysis
API visibility debt is now a governance failure, not a tooling gap. When organisations cannot enumerate their full API attack surface, they cannot enforce ownership, testing scope, or remediation accountability. That leaves undocumented interfaces outside the normal control plane and turns shadow APIs into a standing exposure problem. The practical conclusion is that API inventory must be treated as a governed asset register, not a side effect of tooling.
Identity controls break down when API discovery lags behind delivery. APIs often carry the authentication and authorisation boundaries for workloads, service accounts, and third-party integrations. If the API is missing from inventory, the identity policy attached to it is effectively invisible too. Practitioners should read this as an NHI governance issue as much as an AppSec issue, because machine identity trust is only as strong as the accuracy of the API surface it is bound to.
API attack surface visibility debt: this is the specific failure mode the article exposes, where security teams protect documented interfaces while real interfaces proliferate elsewhere. The result is a control model built on partial knowledge, which always overstates assurance. The practitioner takeaway is that discovery must become continuous, or the organisation will keep certifying a system it does not actually see.
Continuous API testing is becoming a compliance requirement disguised as an engineering task. The article’s references to PCI DSS v4.0.1, the EU Cyber Resilience Act, and ISO 27001:2022 reflect a broader shift toward demonstrable, ongoing testing. That means evidence of coverage matters as much as the scan itself. Teams should assume regulators will increasingly expect proof that API exposure is actively managed across the development lifecycle.
Business logic risk is the hardest gap to close once visibility improves. Even when teams discover the API, they still need to test how it behaves under valid but malicious sequencing, parameter tampering, and object-level abuse. That pushes API security beyond signature-based detection and into control validation. The practitioner implication is clear: visibility is necessary, but behavioural testing is what closes the governance gap.
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.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: NHI Authentication Guide
What this signals
API discovery debt will increasingly show up as identity governance debt. When service accounts, OAuth tokens, and machine-to-machine flows are attached to APIs that no one has fully inventoried, access review cannot give a true picture of exposure. Practitioners should expect API inventory quality to become a prerequisite for credible NHI governance, not a separate AppSec concern.
Continuous testing is becoming the operational floor for API programmes. Evidence from the source article points to a shift away from periodic scans and toward release-aligned validation that can keep pace with modern delivery. For teams that rely on API-driven access, the practical implication is that testing cadence now needs to match deployment cadence, not audit cadence.
For practitioners
- Build a continuous API inventory Map APIs from source code, service meshes, and traffic analysis so undocumented endpoints are identified before they become permanent blind spots.
- Validate authentication and authorisation on live paths Test OAuth, JWT, API key, and service-to-service flows against real requests so broken authentication and object-level abuse are caught in context.
- Tie API ownership to deployment ownership Assign a named business and technical owner to each API, including shadow and internal-only interfaces, so remediation and retirement are not ambiguous.
- Evidence continuous testing for compliance Retain scan results, pipeline logs, and remediation records that show testing occurred repeatedly, not just during quarterly review windows.
Key takeaways
- Incomplete API visibility is now a governance problem because unknown interfaces cannot be owned, tested, or retired on schedule.
- The control failure is not just discovery. Broken authentication and business logic abuse become more likely when APIs sit outside the inventory.
- Teams need continuous discovery, authenticated testing, and named ownership if they want API security evidence to stand up in production and compliance reviews.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article centres on undiscovered APIs and incomplete inventory. |
| API2 — Broken Authentication | Broken authentication is named as a primary threat in the article's API risk discussion. | |
| API6 — Unrestricted Access to Sensitive Business Flows | Business logic abuse and malformed request sequences are central to the article. | |
| Recommendation — Track every API asset continuously and close inventory gaps before testing and governance drift. Validate authentication flows on live APIs and block deployments that fail authentication tests. Test business flows for abuse patterns that bypass intended request sequencing or approvals. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | API inventory and ownership map directly to asset management and visibility controls. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article links API risk to authorization and access scope controls. | |
| Recommendation — Extend asset inventory practices to APIs so security coverage matches the real attack surface. Review API entitlements and authorizations against actual service and workload access paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | API access often depends on service accounts and machine credentials that need lifecycle control. |
| Recommendation — Apply account lifecycle controls to the identities that authenticate to APIs and retire stale access. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article discusses attacker use of API weaknesses to reach data and spread access. |
| Recommendation — Map API abuse detections to credential access and lateral movement behaviours in your threat hunting. | ||
Key terms
- API Attack Surface: The API attack surface is the total set of ways an attacker can interact with exposed application programming interfaces. It includes endpoints, methods, authentication flows, tokens, parameters, error messages, and integrations. In security analysis, it is the full collection of API entry points, trust boundaries, and misconfiguration opportunities that may be abused.
- 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.
- Business Logic Abuse: Business logic abuse occurs when an attacker uses a valid API in a way the application designer did not intend, such as exceeding limits, chaining actions, or misusing workflow assumptions. The API is functioning technically, but governance and policy are failing at the intent layer.
- Authenticated scanning: Authenticated scanning is DAST performed with valid credentials, tokens, or session state so the tester can reach protected application functions. It is essential when important business logic sits behind login or delegated access, because unauthenticated scanning often stops before the real risk surfaces.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programme that supports them.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org