Notifications
Clear all
Topic starter
02/08/2026 9:40 am
TL;DR: APIs are now the exposed control plane for modern applications, and StackHawk argues that attack surface growth is being driven by hidden endpoints, weak authorization, insecure tokens, and incomplete inventory. The governance problem is that discovery, access control, and monitoring are still treated as separate tasks when the risk is system-wide.
NHIMG editorial — based on content published by StackHawk: How To Discover Your API Attack Surface
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.
Questions worth separating out
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.
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.
Q: What breaks when endpoint inventory is incomplete?
A: When endpoint inventory is incomplete, patching, configuration enforcement, and access restrictions all become partial controls.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read StackHawk's guide to discovering and securing your API attack surface →
API attack surface growth: what IAM and AppSec teams need to know?
Explore further
02/08/2026 12:34 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: API attack surface growth is outpacing authentication controls
