API sprawl is not a planning failure. It is the natural consequence of building software that works.
Every microservice that gets extracted from a monolith adds endpoints. Every third-party integration adds a callback or a webhook receiver. Every new product feature adds routes. Every developer who joins the team adds their own service. Every customer who requires a custom integration gets an adapter. The APIs accumulate gradually, purposefully, and then all at once and by the time the security team or the new engineering lead looks at the full inventory, the number is larger than anyone expected.
What that number looks like in practice: a growth-stage SaaS company that has been shipping features for three to four years typically has somewhere between seventy-five and two hundred distinct API endpoints. Not all of them are public-facing. Not all of them are documented. Not all of them are tested. Some of them nobody remembers writing.
This post is built around a specific data set: a security assessment of one such application one hundred and twenty-five API endpoints across a microservices architecture, assessed without manual endpoint configuration, with findings categorized by endpoint type, vulnerability class, and severity. The data tells a specific story about where API vulnerabilities concentrate, which endpoints produce the most risk, and what zero-configuration assessment of a real API portfolio actually produces.
The Application in Context
The application assessed was a B2B SaaS platform in the project management and collaboration space. Four years old. Forty-person engineering team. Microservices architecture with seven distinct services, each with its own API. Documentation for the external-facing API was reasonably complete. Documentation for internal service-to-service APIs was sparse. Documentation for administrative endpoints was essentially nonexistent.
Total endpoints discovered: 125.
The discovery process the endpoint mapping that precedes any security testing was itself a finding. The engineering team's estimate of their total API surface, before the assessment, was "somewhere around sixty to eighty endpoints." The actual count was more than fifty percent higher than their upper estimate. Thirty-seven endpoints were not in any documentation. Seventeen were endpoints that multiple senior engineers on the assessment team had never seen referenced in any architectural diagram.
This gap between estimated and actual surface area is consistent across assessments of organizations at similar stages. The API surface that developers actively think about is substantially smaller than the API surface that actually exists and accepts requests. The endpoints that nobody is thinking about are the endpoints that nobody is testing and they are disproportionately represented in the findings.
The Twenty Vulnerabilities: Distribution and Concentration
The assessment identified twenty vulnerabilities across the hundred and twenty-five endpoints. Severity distribution:
- Critical (CVSS 9.0+): 3 findings
- High (CVSS 7.0-8.9): 7 findings
- Medium (CVSS 4.0-6.9): 10 findings
All three critical findings and five of the seven high findings were in the thirty-seven undocumented or rarely-accessed endpoints. The pattern is not coincidental. Endpoints that are not in active development receive less ongoing attention. They are not reviewed in the security considerations of sprint planning. They are not included in the scope of QA testing. They accumulate technical debt, including security debt, at a rate that correlates with how forgotten they are.
The documented, actively maintained endpoints were not clean they produced five high findings and seven medium findings but the finding rate per endpoint was roughly half that of the undocumented surface.
Vulnerability Class Breakdown: What Actually Appeared
The twenty findings broke down across six vulnerability classes. Understanding which classes appeared where helps prioritize which tests matter most at scale.
Broken Object Level Authorization (BOLA): 8 findings (4 high, 4 medium)
BOLA was the most prevalent class and appeared across the widest variety of endpoint types. The pattern was consistent: resource endpoints that accepted an object ID as a URL parameter or request body value, returned or modified the corresponding resource, and did not verify that the authenticated user owned or had permission to access that resource.
The highest-severity BOLA findings were in internal service-to-service endpoints that had been exposed on the same API gateway as the external-facing API without adequate isolation. These endpoints had been designed with the assumption that they would only be called by trusted internal services the authorization check was essentially "is this request coming from an internal IP range?" rather than "is this authenticated user permitted to access this resource?" Once the gateway configuration changed to serve external traffic on the same infrastructure, the internal assumption was no longer valid.
Broken Function Level Authorization (BFLA): 4 findings (2 critical, 2 high)
Function-level access control failures where users could call endpoints intended for higher-privilege roles appeared in both administrative endpoints and in feature-specific endpoints where the role check had been partially implemented. The critical findings here involved endpoints that could modify user roles, suspend accounts, and access billing information belonging to other organizations.
Both critical findings were in endpoints that had been built for internal admin tooling and had never been exposed in the external API documentation. They had been added to the API gateway during a refactoring that moved the admin console to use the same API as the external product. The refactoring correctly moved the endpoints. It did not correctly restrict their access to administrator-level sessions.
Injection (SQL / NoSQL / Command): 3 findings (1 critical, 2 high)
Three injection vulnerabilities across the endpoint set. The critical finding was a NoSQL injection in a search endpoint a filter parameter that accepted a JSON value and passed it directly to a MongoDB query without sanitization. The parameter accepted query operators including $where, which allows arbitrary JavaScript execution in older MongoDB configurations.
The high-severity SQL injection findings were in endpoints that had been recently migrated from a legacy ORM to a new query builder. The migration had not uniformly applied parameterized queries several endpoints in the migrated service used string concatenation for query construction in code paths that handled less common filter parameters. The common filter parameters had been migrated correctly. The edge cases had not.
Sensitive Data Exposure: 2 findings (2 medium)
Two endpoints that included data in their responses that should not have been visible to the requesting user's role: one that included hashed password values in a user profile response intended for a limited-scope API client, and one that included internal metadata database row identifiers, internal status codes, processing timestamps that facilitated enumeration of internal system state.
Security Misconfiguration: 2 findings (2 medium)
Two misconfigured endpoints: one with CORS configured to allow any origin with credentials (the Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true pattern), and one with verbose error responses that included stack traces and internal library names in error responses from the production environment.
Excessive Data Exposure: 1 finding (1 medium)
One endpoint that returned the full user object including fields relevant only to administrative operations rather than a projection scoped to the fields needed by the requesting client type.
The Zero Configuration Story: How the Surface Was Discovered
The "zero manual setup" claim in the title refers to the discovery phase: the endpoint mapping that produced the hundred-and-twenty-five-endpoint inventory required no prior knowledge of the application's structure, no access to internal documentation, and no manual specification of endpoints to test.
The discovery process used by an autonomous AI security agent follows the same logic an attacker would use when approaching an unfamiliar application: start from the root, read what the application reveals about itself, follow every reference to additional structure, and build a map from the outside in.
For this application, the discovery sources were:
JavaScript bundle analysis. The front-end application loaded several JavaScript bundles that contained route definitions, API client configurations, and error handling code that referenced internal endpoint paths. Analysis of these bundles revealed forty-three endpoints not visible from the application's surface navigation.
OpenAPI and Swagger endpoints. The application exposed a Swagger UI at /api/docs (internal only, but accessible from the authenticated session) and an OpenAPI specification file at /api/v2/openapi.json. The specification covered the external-facing V2 API sixty-one endpoints but did not document the V1 endpoints still in use for backward compatibility or the internal service endpoints.
V1 API discovery from response patterns. Several V2 endpoints included deprecation headers referencing V1 equivalents. Following these references, and probing adjacent paths on the V1 prefix, revealed twenty-two additional endpoints. Eleven of these were the undocumented internal service endpoints that produced the highest-severity findings.
Error response analysis. Some 404 responses from the API gateway included error messages that distinguished between "path not found" and "service unavailable" a distinction that revealed the existence of additional service prefixes that the gateway was routing to but that were temporarily down during the assessment. Probing these prefixes during a later window revealed seven additional endpoints.
The total discovery time, from initial contact to complete endpoint map: forty-seven minutes. No human analyst. No documentation access. No prior knowledge of the architecture.
The Finding That the Security Team Missed: Internal APIs on the Public Gateway
The most significant structural finding from the assessment was not a specific vulnerability it was an architectural condition that produced multiple vulnerabilities and that the engineering team had not recognized as a security concern.
When the company had migrated from a monolithic API to a microservices architecture eighteen months earlier, the API gateway had been configured to route requests to the new services. Internal service-to-service communication had been moved to the same gateway for operational simplicity it was easier to maintain one routing table than to manage separate internal and external routing infrastructure.
The consequence: internal service endpoints designed with the assumption of trusted callers were accessible from the internet through the same gateway that served external API traffic. The only protection was that these endpoints were not documented and were not referenced in any external-facing material.
Security through obscurity is not a control. An assessment that discovers endpoints systematically the way an attacker would finds undocumented endpoints as readily as documented ones. The absence of documentation about an endpoint does not prevent an attacker from finding it. It prevents legitimate developers from knowing it exists, which means it prevents legitimate security testing from being applied to it.
Of the eleven undocumented internal endpoints found through the V1 API discovery and error response analysis, seven had authorization logic that assumed internal-only callers and therefore applied minimal access control. Three of these produced the critical and high-severity BFLA findings. Two produced BOLA findings where the authorization check was a simple IP-range check rather than an authenticated user ownership verification.
What Zero Manual Setup Actually Enables
The assessment methodology no endpoint specification, no documentation provided, discovery from the application surface outward produced a materially different finding set than a targeted assessment with a known endpoint list would have.
A targeted assessment with the engineering team's estimated endpoint list would have covered approximately seventy-three endpoints. It would have missed the thirty-seven undocumented endpoints and therefore would have missed all three critical findings, five of the seven high findings, and the architectural condition that produced them.
This is not a criticism of targeted assessment methodology it has its place, particularly for deep testing of specific high-risk components. It is an observation about what systematic, autonomous, surface-first discovery produces when the actual surface is significantly larger than the believed surface.
The zero-manual-setup claim also refers to a different efficiency: the time required from "point the tool at the application" to "results are available" did not include hours of endpoint specification, API documentation ingestion, or authentication configuration. The agent created its own test account, navigated its own authentication flows, and built its own surface map. The security team's involvement in configuring the assessment was minimal.
For a hundred-and-twenty-five-endpoint application, the total assessment time from initial contact to findings report was approximately four hours. The equivalent human-led assessment against a known endpoint list, at reasonable tester efficiency, would take two to three days. The autonomous assessment with discovery included would take significantly longer if done by a human, because the discovery phase alone finding the undocumented endpoints is where the most time-consuming investigative work lies.
What This Means for Security Program Design
The findings from this assessment suggest several principles for organizations managing API sprawl.
The endpoint inventory is a security artifact. An organization that does not know how many API endpoints it has cannot know whether those endpoints are secure. Maintaining an accurate, current inventory of API endpoints including internal service endpoints and endpoints that are not actively developed is a prerequisite for a meaningful API security program.
Finding rate is not uniform across the API surface. The endpoints that are least-attended, least-documented, and least-remembered produce vulnerabilities at a higher rate than actively maintained endpoints. A security program that tests only the documented, known surface will systematically under-cover the highest-risk portion of the actual surface.
Discovery is part of security testing, not a prerequisite for it. An assessment methodology that requires complete endpoint specification before testing begins is an assessment methodology that covers only the known surface. Autonomous discovery, which builds the endpoint map from the application outward, finds what the attacker would find including the thirty-seven endpoints that the engineering team did not know were accessible.
Internal APIs that become externally accessible require re-authorization review. Architecture changes that affect the trust context of an endpoint moving internal services onto a public gateway, adding external-facing routes to a previously internal service, changing network topology that affects which clients can reach a service require a review of the authorization logic that was designed for the previous trust context. Authorization logic designed for trusted callers is not appropriate for untrusted ones.
The Coverage Question at Scale
The question that the hundred-and-twenty-five-endpoint dataset makes concrete is one that every engineering organization with significant API surface has to answer: how do you maintain meaningful security coverage across an API portfolio that is larger than any one person or team knows in detail?
Manual penetration testing at regular intervals covers a portion of the surface, but the portion it covers is determined by what the testing team can discover and exercise within a time-bounded engagement. For a hundred-and-twenty-five-endpoint application, a one-week engagement will cover the documented surface and may or may not reach the undocumented portions depending on how much of the engagement time goes to discovery.
Automated DAST tools cover the unauthenticated surface and whatever authenticated surface they can reach with a provided session cookie but they cannot test authorization across accounts, cannot exercise multi-step workflows, and cannot evaluate the behavioral correctness of the application's access control logic.
Autonomous AI-based security testing covers the authenticated surface through dynamic discovery, tests authorization across multiple accounts by creating its own sessions, and exercises workflows as a real user would including the workflows that lead to the critical BFLA findings in the administrative endpoints that had been moved to the public gateway.
The coverage is not perfect. Twenty findings across a hundred-and-twenty-five endpoints, assessed in four hours, is a different result from what a seasoned human tester with two weeks and deep application familiarity might produce. The question is not whether one approach is superior in all dimensions it is which approach provides the right coverage model for the right stage of the security program.
For API sprawl specifically, the autonomy matters most. A security approach that requires a human to enumerate the endpoints before testing them will always lag behind an API surface that is growing faster than humans can enumerate it.
Closing: The Thirty-Seven Endpoints Nobody Was Watching
The security story of this assessment is not twenty vulnerabilities across a hundred-and-twenty-five endpoints. That number is the answer to "how many problems did you find?"
The more important story is thirty-seven endpoints that the engineering team did not know were accessible. Seventeen that senior engineers had never seen in an architecture diagram. Eleven that had been designed for trusted internal callers and were now accepting requests from the internet. Three critical vulnerabilities in endpoints that no existing security test no prior penetration test, no automated scanner, no code review had ever examined.
API sprawl is not a security problem in itself. It is the condition that makes security problems invisible. An endpoint that exists but that nobody is thinking about is an endpoint that nobody is testing. An endpoint that nobody is testing will accumulate security debt at the rate of its development, and its development happened it is sitting there, running, accepting requests just waiting for someone with the right questions to ask them.
The discovery-first, autonomous-assessment methodology finds the endpoints nobody is watching. The vulnerabilities in those endpoints are frequently the most significant ones. The engineering team's security posture is not defined by how secure the endpoints they know about are. It is defined by the full surface including the thirty-seven endpoints at the edge of the inventory where the critical findings live.
Axeploit's discovery-first approach starts from the application root and maps the full API surface before testing begins finding the endpoints that are not in the documentation, the services that got added to the gateway without a security review, and the internal APIs that became externally accessible when the architecture changed. The hundred-and-twenty-five-endpoint assessment described in this post reflects exactly this methodology: zero endpoint configuration, complete surface discovery, and vulnerability testing across the actual surface rather than the estimated one.
