Backstage is an internal developer portal assembled from a catalog, templates, documentation, and plugins. Authentication tells Backstage who the user is and can delegate access to external systems. Authorization decides which catalog operations, templates, and plugin actions are allowed. The two layers are easy to confuse, and the gap between them is where a plugin can expose more than the portal owner intended.
Backstage's authentication documentation describes two purposes: sign-in and identification of users, and delegation of access to third-party resources. It also notes that identity management and the sign-in page do not protect the frontend bundle by themselves. A public entry point or a misconfigured backend can expose the interface even when sign-in appears to work.
Authentication is not a permission policy
Backstage's permission framework gives integrators a policy layer that plugin backends enforce. A plugin should check the relevant permission before it returns data or performs an action. The catalog plugin may have different permission decisions from the scaffolder, TechDocs, or a custom integration.
Review the policy at the plugin level. An allow-all policy is useful for development and dangerous in a production portal. A custom policy that checks a user's group should also verify that group membership is resolved from a trusted identity provider and that the group does not include guest or temporary accounts.
Test a user with no role, a normal engineer, a platform administrator, and a service identity. Confirm that each one receives the expected catalog entities, template actions, and plugin resources. A hidden button is not evidence of backend authorization.
Service-to-service tokens need a narrow scope
Backstage supports service-to-service authentication. The documentation describes tokens or requests that can be limited to a plugin and named permissions. That limitation reduces the blast radius of a leaked service credential. A token intended for the catalog should not be able to invoke a deployment plugin or read an unrelated backend.
Inventory service identities and the plugin permissions they request. Rotate tokens after an application change and remove unused credentials. Store them outside the frontend bundle. A service token embedded in a browser-delivered configuration file is effectively public.
Review plugin dependencies as part of the permission model. A plugin may call an external API with a separate credential, and the user's Backstage identity may be delegated to that API. The external system must validate the delegation rather than trusting a username or group header supplied by the frontend.
Use the threat model as a review checklist
Backstage publishes a threat model that discusses authentication, plugin behavior, and the boundaries of the platform. Use it to ask concrete questions: which plugins are installed, who maintains them, which backend routes are exposed, what secrets the plugin stores, and what happens when a plugin is removed or upgraded?
Keep the Backstage version and plugin inventory under change control. A community plugin can add a route, a dependency, or a token flow that changes the portal's security properties. Review the plugin's permissions before installation and after an upgrade.
Protect the software catalog as an asset inventory. It may reveal repository names, ownership, deployment URLs, and operational contacts. Restrict sensitive entity fields and test whether the catalog API returns data to an unauthorized user.
Measurement
ZoomEye's app="Backstage" fingerprint returned a small count, which is consistent with a product that is often deployed behind an organization's identity layer or may not expose a distinctive public page. A small count does not make the fingerprint complete or prove that every deployment is internal.
On 2026-11-11, a count-only query with dork app="Backstage", sub_type=all, page 1, and page size 1 returned 24 matching assets. The deterministic search link is the Backstage ZoomEye query. The total describes matching product assets, not vulnerable installations or exposed service tokens.
Use the result as a lead for checking owned domains and known portal hosts. A missing match is not evidence that no Backstage instance exists, because authentication, network filtering, and fingerprint variation can hide a deployment.
Response to a suspected portal compromise
Revoke the affected user or service token, review permission-policy changes, and inspect plugin backend logs for catalog reads, template executions, and external API calls. Preserve the Backstage configuration, plugin versions, and identity-provider group mapping before changing roles.
If a service token could access a deployment system, review that system's logs and rotate its credentials. If a plugin stored a third-party token, revoke the token at the provider and determine which user or service identity authorized it.
After containment, reduce plugin permissions, remove unused plugins, and require an explicit owner for each service-to-service identity. Backstage's value is that it brings many developer workflows into one place. The permission design must keep one compromised workflow from becoming a path to all of them.