Backstage catalogs expose organizational structure when identity is optional
Backstage is a developer portal with a software catalog, templates, documentation, and plugins. A catalog can show service ownership, repository links, deployment relationships, and on-call context. That information helps engineers. It also helps an attacker map production dependencies. The security boundary depends on authentication and an authorization policy that is actually enabled.
A standalone ZoomEye SDK query using sub_type=all, page 1, and page size 1 returned 24 matches for app="Backstage" and 4,930 for title="Backstage" on 30 October 2026 at 00:40 UTC. The title query is broad because the word appears in many contexts. The app count is narrow but still requires ownership validation before treating a host as an organizational Backstage deployment.
Separate sign-in from authorization
Backstage authentication identifies users and can delegate access to third-party resources. Authorization is a separate framework that decides whether an identity may perform an action on a resource. Backstage's authentication documentation notes that the sign-in page only blocks external access under the new backend system when the default auth policy is disabled through a specific dangerous configuration option. That behavior is not a substitute for a permission policy that limits sensitive catalog and action access.
Review the sign-in resolvers that map identity-provider users to Backstage identities. A resolver can reject a user or assign a group membership. Careless mapping can give an external identity the wrong catalog owner role. Test users from each identity provider, a removed user, and a user whose group membership changed.
Classify catalog data
Service names, repository URLs, team ownership, deployment targets, and incident contacts are useful reconnaissance. Control read access to sensitive catalog entities and plugin actions. A public developer portal may be acceptable for open-source documentation but inappropriate for an internal environment map.
Review plugin permissions as part of the same policy. A catalog read grant does not automatically authorize a scaffolder action, Kubernetes plugin, CI plugin, or deployment tool. Each plugin should declare the actions it enforces and the resources those actions affect. Audit installed plugins for ones that expose data without a permission check.
Inspect the exposure path
Confirm the backend and frontend URLs, reverse-proxy rules, and identity-provider callback configuration. A frontend link that appears public can call a backend API that has a separate route. Test both the initial page and the API response. Check that internal service-to-service credentials are not bundled into browser assets.
For owned instances, compare the app match with the organization's asset inventory and then review the active auth policy. The count is not a claim that 4,930 sites expose catalogs. It is a reminder that developer portals need the same access-control review as source code and CI systems. A catalog that answers "who owns this production service" to an unauthenticated user is an organizational disclosure even when no code is exposed.
Top comments (0)