VULNBANK API SECURITY ASSESSMENT

PART 4 — When Internal Endpoints Become Part of the Public API Surface

API9: IMPROPER INVENTORY MANAGEMENT

During API reconnaissance, I reviewed the API documentation exposed by VulnBank.

The documentation contained a section explicitly labelled:

Internal — Internal-only endpoints for SSRF demonstration

Under this section, several internal endpoints were publicly visible, including:

This is significant because these endpoints are explicitly identified as internal-only, yet they are visible through the publicly accessible API documentation.

An external user therefore gains direct knowledge of functionality that should not form part of the public API surface.

Why This Matters

API inventory management is not simply about documenting available endpoints.

It also requires understanding:

• Which endpoints are public
• Which are internal
• Which are deprecated
• Which API versions are active
• Which endpoints should be accessible to external users

In this case, the application effectively exposed information about its internal attack surface through its API documentation.

An attacker does not need to discover /internal/secret through blind enumeration when the application has already documented it.

Connection to the SSRF Finding

This discovery became particularly relevant during the SSRF testing documented in Part 3.

The /upload_profile_picture_url functionality accepted a user-controlled URL.

Using the internal endpoint identified during API reconnaissance, I tested:

http://127.0.0.1:5000/internal/secret

http://127.0.0.1:5000/internal/secret

as the supplied URL.

The server subsequently retrieved the internal resource, confirming the SSRF vulnerability.

This creates an important relationship between the two findings:

API9 — Improper Inventory Management
                ↓
Internal endpoint exposed
                ↓
Internal attack surface identified
                ↓
API7 — SSRF
                ↓
Internal endpoint accessed

API9 — Improper Inventory Management
                ↓
Internal endpoint exposed
                ↓
Internal attack surface identified
                ↓
API7 — SSRF
                ↓
Internal endpoint accessed

The API9 issue did not cause the SSRF. Rather, the exposed API inventory made the internal target easier to identify during testing.

REMEDIATION

Internal endpoints should not be exposed through public API documentation.

The application should:

• Separate internal and public API documentation.
• Restrict internal API documentation to authorized users.
• Remove internal endpoints from externally accessible API specifications.
• Maintain an accurate inventory of public and internal APIs.
• Review API documentation as part of deployment.
• Ensure internal endpoints have their own access controls rather than relying on obscurity.

Most importantly, removing an endpoint from documentation is not a substitute for access control.

If /internal/secret is genuinely internal, the application should also prevent unauthorized clients from reaching it.

FINAL THOUGHT

The interesting part of this finding wasn't simply that VulnBank had internal endpoints.

It was that those endpoints were explicitly documented as internal-only while remaining visible through the externally accessible API documentation.

That creates unnecessary visibility into the application's internal attack surface. And in this assessment, that visibility became useful during SSRF testing.

You cannot properly manage an API attack surface if internal functionality is treated as part of the public inventory.

This is why API inventory management is a security concern, not just a documentation problem.