No. According to the Backstage documentation, its endpoints are not protected by default and all actions are available to anyone until you configure authentication and the permission framework. A developer portal is a map of your systems and a button for creating repositories, so it deserves a deliberate lockdown before real data goes in.
Definition
Backstage is an open source framework for building an internal developer portal. It has a software catalog, a scaffolder that creates new components from templates, and a plugin system. "Secure by default" would mean that a fresh install enforces sign-in and authorization. The docs say it does not, and that is a reasonable choice for a framework, as long as you know it.
Three layers to configure
| Layer | What it does | Default state |
|---|---|---|
| Authentication | Proves who the user is, through a sign-in provider | You choose and configure providers |
| Permission framework | Decides which users may take which actions on which resources | Endpoints unprotected, all actions available |
| Public entry point | Keeps the main app bundle away from unauthenticated visitors | Frontend bundle not protected without extra setup |
The docs describe the permission framework as flexible: role based access control, attribute based access control, custom code, or an external authorization provider can all sit behind it. Plugin authors declare which resources and actions can be placed behind authorization, and the integrator writes the policy.
Steps to lock it down
- Turn on a real sign-in provider. The auth docs show a guest option for non-production use and note that you will most likely not want guest access in production. Remove it from the production config.
- Check how you run the backend. The documentation notes that the sign-in page only blocks external access when using the new backend system and without certain overrides set, so read that section against your own setup.
- Enable the permission framework and write a policy. Start deny by default for write actions such as running templates and unregistering catalog entities, then open up deliberately.
- Consider the public entry point. The docs say the frontend bundle is not protected from external access, and that protecting it uses an experimental public entry point that splits login pages from the main bundle.
- Review static tokens for service to service calls. The docs describe static tokens as random values handed to external callers who want to call backend plugins. Treat each one like a credential: owner, scope, rotation date.
- Put the portal behind your normal network and identity controls as well. Defense in depth is cheap here.
Why the portal is a high-value target
A catalog lists services, owners, repositories and sometimes links to dashboards and runbooks. The scaffolder can create repositories and, depending on configuration, publish code. Plugins that talk to source control, CI and cloud accounts hold tokens. If an attacker reaches the portal, they get both a map and some of the keys.
That is also why vetting plugins matters. See our post on how to vet a community Backstage plugin.
A quick self-test
Open the portal in a private browser window. Can you see the catalog? Call a backend plugin endpoint without a token. Does it answer? Try running a template as a user who should not be able to. If any of those succeed, you have found your first ticket.
Where Safeguard fits
Safeguard's asset discovery and SBOM and dependency scanning can help inventory the packages and services behind a portal like this, and policies and gates can check changes before merge. You can try the free scan at gold.safeguard.sh/scan.
Quick check
Does the Backstage sign-in page alone protect the backend?
Not necessarily. The documentation says sign-in only blocks external access in certain backend setups, so verify your own configuration by testing unauthenticated requests.
Is guest sign-in acceptable in production?
The docs present it as useful for non-production and say you will most likely not want it in production.
Sources
- Permissions overview, Backstage documentation
- Authentication in Backstage
- Service to service auth, Backstage documentation
- Enabling a public entry point, Backstage documentation
Last reviewed: 19 October 2026.
