Why the Backstage frontend bundle stays readable behind sign-in
A production Backstage portal can show a sign-in page while its JavaScript bundle is served to anyone who can reach the host. The bundle is static code that the browser downloads before any user authenticates, so sign-in controls access to catalog data and API responses but does not control who can read the application code. Treat the bundle as public by default unless you have tested otherwise. Before you plan any control, request the main JavaScript files directly from a machine outside your sign-in path and confirm what comes back. Then check whether your build embeds configuration values in those files.
A team needs this page when the portal is an internal system in a regulated environment, or when the code it serves would reveal more than the team wants outsiders to see. Examples include internal route names, internal hostnames or service names that appear in frontend configuration, and the list of installed plugins. Review the frontend keys in app-config.yaml and confirm which values your build exposes to the browser. The experimental public entry point is one way to separate content that can be served before sign-in from content that needs a session. Confirm its current status, its exact behavior and its support position in the release line you run before you build on it.
If the bundle is a concern, an authenticating reverse proxy or gateway placed in front of the whole host is often the simpler fix, because it blocks unauthenticated requests to static assets as well as to the API. The trade-off is that the proxy becomes part of your sign-in design, so session lifetime, logout and header trust need explicit owners. Whichever path you choose, keep sign-in resolvers mapping every provider to the same identity and keep guest access off in production, as the Backstage authentication documentation advises. Write down which artifacts must stay private and test that the chosen control blocks them.
Backstage public entry point and authenticating proxy options compared
This table compares three ways to keep Backstage frontend code away from anonymous visitors: a public bundle with API-only sign-in, the experimental public entry point, and an authenticating proxy in front of the whole app. Read each row against your threat model, and confirm the current behavior of the experimental public entry point in the release notes before relying on it.
| Option | What it protects | What it leaves exposed | Operational cost and main risk |
|---|---|---|---|
| Public bundle, sign-in at the API layer | Catalog, template and TechDocs data returned by authenticated API calls | The full JavaScript bundle, including route names, plugin names, internal hostnames and configuration baked into the frontend | Lowest setup effort, but the bundle reveals internal structure to anyone who loads the page; the main risk is assuming the sign-in page hides the app |
| Experimental public entry point | Splits public and authenticated frontend code so that authenticated modules are not served to anonymous users | Whatever is classed as public, plus any shared code that reaches the browser; the split depends on how plugins are written | Requires a frontend entry point change and testing of each plugin's routes; the feature is experimental, so confirm its current behavior and known limits in the release notes before production use |
| Authenticating proxy in front of the whole app | Every request, including the static bundle, is checked by the identity provider before Backstage receives it | Anyone who passes the proxy's sign-in (for example, a broad identity group), and anything the proxy is not configured to cover such as health endpoints or callbacks | Recurring cost of proxy policy and identity group maintenance; the main risk is a path or host rule that skips the proxy, so test unauthenticated requests to every route |
| Who should choose it | Teams that need a quick, low-change control and accept that the bundle is visible | Teams that want in-app separation and can absorb plugin testing and experimental feature changes | Teams with an existing supported proxy or identity provider and a need to keep the bundle off the public internet |
Choosing the public entry point or an authenticating proxy by situation
If your organization already places internal applications behind an identity-aware proxy or zero-trust gateway, that layer is usually the simpler control for the Backstage frontend bundle. The gateway authenticates the browser before any file leaves your network, so the bundle is never served to an anonymous visitor. The public entry point adds a second, experimental mechanism that your team would have to understand and keep working alongside the gateway.
- Reuse the existing policy. Access rules, device checks and session lifetimes already live in the gateway, so Backstage inherits them without new configuration.
- Keep the first sign-in step in one place. Backstage still needs its own sign-in resolver for catalog identity, but the gateway handles the initial authentication.
- Confirm how identity reaches Backstage. If Backstage trusts identity headers from the proxy, only the gateway should be able to reach the backend. Test this path directly.
- Retest after gateway changes. Policy edits can silently widen or narrow who sees the bundle, so include the Backstage host in every gateway change review.
Confirm with your gateway vendor how it authenticates static asset requests and whether it can protect the whole host or only selected paths. Verify with a test account that should be denied, because a gateway that protects the API but not the asset path leaves the bundle open.
If Backstage is reachable only from a private network, such as an internal corporate network or a VPN, the network boundary is the simpler control to own. Anyone who cannot reach the host cannot download the bundle, so exposure is limited to people your network already admits. The public entry point solves a problem this model does not have, so it rarely justifies its experimental risk here.
- Verify the boundary. Confirm that no public load balancer, DNS record, ingress or preview environment points at the Backstage host.
- Account for remote staff. Remote access through a VPN makes that VPN's authentication the outer gate, so its MFA and session settings matter for Backstage.
- Watch for drift. A later ingress rule, CDN or shared cluster setting can expose the host unintentionally, so scan it on a schedule.
- Keep sign-in on. Guest access should be off in production, and network reach does not replace identity checks inside the portal.
- Treat the bundle as internal. Anyone with network access can read the bundle, so plugin names, internal hostnames and API paths in it should be assumed visible to all internal users.
Check the boundary from an external network that has no VPN access, and confirm that the host does not answer.
Some organizations want documentation or a status page open to outside readers while the rest of the portal stays private. A single proxy in front of everything also hides those public pages, so the question becomes how to separate public content from the authenticated application. The public entry point is designed to split which parts of the frontend are open, which can help when the public surface is small and well defined. Larger or changing public surfaces are usually easier to manage on separate hosts.
- Publish public content separately. Serving documentation as its own static site on another hostname keeps it out of the authenticated bundle.
- List every public route. Public pages, status views and their assets must be enumerated before go-live, and the list must be owned.
- Test anonymous access per route. Confirm that the portal bundle and its API calls are denied to anonymous users while the public pages load.
- Expect experimental change. Behavior may shift between Backstage releases, so pin versions and rerun the anonymous tests on every upgrade.
- Review what the bundle reveals. Internal service names and API paths in a publicly reachable bundle can be sensitive even when the pages are meant to be public.
Compare the public route list with the files actually served to an anonymous browser, and treat any difference as a finding to resolve before launch.
A proxy is not free to run. Its cost includes the product or license, the infrastructure it runs on, staff time to configure and patch it, and the testing that follows each change. When that budget does not exist, the cheapest effective control is usually to restrict network reach first and enable sign-in through an identity provider you already operate. The experimental public entry point adds recurring testing work, so treat it as an option only when a public page is required and the team accepts that risk.
- Start with network restriction. Limiting who can reach the host often reduces exposure the most at the lowest ongoing cost.
- Use the identity provider you have. Sign-in through an existing provider keeps authentication inside Backstage without buying a gateway.
- Check for existing enforcement. Ingress controllers, cloud load balancers or existing platform components may offer authentication you already pay for, so ask the platform team before buying anything.
- Budget for testing. Verifying which assets are split and retesting each release is recurring staff work that the public entry point creates.
- Record the accepted risk. If the bundle remains reachable, document who accepted the exposure, what it reveals and the date of the next review.
Ask your platform team to list the components that can already enforce sign-in before you choose, since an existing control often answers the question at no new licensing cost.
What the Backstage frontend bundle can reveal to outsiders
A sign-in page hides the screen, not the code. Everything the browser needs to render the portal is shipped as JavaScript that anyone can download, so the bundle is a readable map of the deployment. The cards below cover what that map can show and what to inspect in the built output before go-live.
Internal route and plugin names
Route paths and plugin identifiers are compiled into the frontend so the app knows what to render. An outsider reading the bundle can list internal areas such as admin, catalog kinds or plugin pages, even when those pages redirect to sign-in. Search the built output for route definitions and plugin mount points, and decide which names you are comfortable exposing. Confirm that hidden routes do not carry data in their component code.
Backend base URLs and hostnames
The frontend needs the backend address to make API calls, so the production backend hostname and sometimes internal service names end up in the bundle. These values show where your backend lives and which environments exist. Check the built files for every hostname, port and path prefix, and compare them with what should be public. Confirm whether internal-only names appear at all.
Enabled features and sign-in providers
The configuration that turns features on and off is also embedded in the frontend. Provider names such as the identity system you use, and flags for guest access or experimental features, reveal how sign-in is built and what an attacker might target first. Review the sign-in provider list and feature flags in the built output, and remove any flag that exists only for development.
Public configuration values
Anything marked as frontend configuration in the app config is copied into the bundle, and that includes values that look harmless, such as client identifiers, tenant names or organization identifiers. Client identifiers are often public by design, but other values may not be. Compare the frontend section of your app config with the built output and classify each value as public or internal before release.
Third-party script references
Analytics, error reporting, font and widget scripts loaded by the portal appear in the bundle as URLs and account identifiers. These references show which vendors you use and can reveal tracking account IDs. Search the built files and the HTML shell for external domains and script tags, and confirm that each one is approved, required and loaded only when needed.
Setting up the frontend split and verifying what is public
This sequence separates the Backstage frontend code and configuration that may be served without sign-in from the parts that must stay behind authentication, then proves the result from outside the network. The output is a staging build and a recorded check showing which files and values an unauthenticated client can retrieve.
Inventory frontend routes and configuration values
The platform engineer who owns the Backstage app lists every route in the frontend app, every plugin that registers a page, and every key in the frontend-visible configuration. Keys under the frontend section of app-config are compiled into the JavaScript bundle, so each one should be treated as public unless proven otherwise. Record catalog names, internal hostnames, feature flags and any value that identifies an integration. The step is done when the list has one row per route and per config value, with a column for who should see it.
Decide which code may be public
Working with the security lead, mark each route and bundle chunk as public, authenticated or not applicable. Sign-in pages, the static shell and generic assets are usually candidates for public access. Plugin pages that render catalog data, scaffolder forms or internal links should remain behind sign-in. Confirm the decision with the owner of each plugin. The output is a signed-off classification that becomes the acceptance test in the later steps.
Configure the split in staging
Choose the mechanism that fits the classification. Either use the experimental public entry point in the frontend build, or place an authenticating proxy in front of the whole app and let it decide which paths reach the bundle. Exact configuration keys and entry point names change between releases, so take them from the Backstage documentation for the version you have installed, not from older examples. Apply the change only in a staging environment that mirrors production hostnames and TLS. Done means the staging app starts and signed-in users can reach all their pages.
Build the frontend bundle
The build engineer produces the frontend artifacts from the staging configuration and the same commit intended for production. Inspect the output directory and list the generated files and their sizes. Search the built JavaScript for any configuration value that the inventory marked as internal. A match means a value that was assumed to be private is compiled into a file that anyone can download. Done means the build completes and the list of files and the search results are saved with the change record.
Verify with an unauthenticated client
From a host outside your network, or with a client that holds no session cookie and no token, request the root page, each public route, each asset path and the static configuration endpoint. Expect the public routes to load and protected routes to redirect to sign-in or return an authorization error. Compare the downloaded files with the build list from the previous step. Done means every response matches the classification, and any file or value that should be hidden is either absent or confirmed as acceptable in writing.
Repeat the check with a signed-in account
Sign in with a standard user account and a restricted account, then confirm that each route and data call behaves as the classification says. This catches cases where a page loads its data from a backend endpoint that is still open, even though the page itself is protected. Record which endpoints each account reaches. Done means the restricted account sees no data it should not see, and any gap is logged as a defect before the change moves forward.
Promote or roll back the change
If every check passes, the platform team schedules the same configuration for production and reruns the unauthenticated check there. If a check fails, revert the staging configuration to the previous version, rebuild, and rerun the unauthenticated client test to confirm the earlier state. Keep the rollback path tested before production, so the team knows exactly which build and configuration to restore. Done means production serves only the approved files and values, and the rollback steps are documented for the next upgrade.
Security and operating controls for the frontend exposure
The sign-in page is not the only thing standing between a visitor and your Backstage catalog, because the bundle itself is served to anyone who can reach the host. The controls below keep sensitive values out of that bundle, verify what it contains after each upgrade, and make sure sign-in and proxy activity can be traced to a named identity. Each control has an owner, and the retest step ties them to the release cadence.
Keep secrets out of frontend config
Anything under the frontend section of app-config is compiled into JavaScript that every browser downloads, so it is public by design. Platform engineering should keep tokens, client secrets and internal hostnames that grant access out of that section and in backend-only configuration. Check the frontend configuration with a review step in the deployment pipeline, and treat any value that looks like a credential found in the built bundle as an incident to rotate.
Review the bundle on each upgrade
Each upgrade can add plugins, change default configuration or pull in new frontend dependencies, so the built bundle changes even when your own code does not. Security engineers should search the generated static files for configured hostnames, tokens and unexpected plugin routes, and compare the result with the previous build. Ask the platform team to keep the diff as release evidence so that a reviewer can see what changed.
Disable guest access in production
The authentication documentation advises against offering guest access in production, because a guest session lets an unauthenticated visitor reach portal features. Platform engineering should confirm that no guest provider is configured in the production app-config and that the sign-in page offers only your organization's providers. Security should test this from an unauthenticated browser session after every configuration change, not only at initial launch.
Map every provider to one identity
The authentication documentation recommends sign-in resolvers that map every provider to the same identity, so a user who signs in with GitHub and with your corporate directory lands on one catalog user. Identity owners should define the resolver rules once, test them with accounts from each provider, and confirm that no provider can create a second user for an existing person. Where two providers can claim the same email address, the resolver should refuse the login rather than guess.
Log proxy and sign-in events
Sign-in attempts, failed resolver matches and calls that pass through the proxy are the events that show whether someone is probing the public entry point. The security team should define which events are retained, where they are shipped, and who reviews them, and confirm that the proxy logs include the caller identity and the upstream path. Confirm with your own log platform that these events arrive in a searchable form before relying on them.
Retest after each release line change
Backstage ships a main release line monthly and a next release line weekly, so the frontend can change more often than most portal teams expect. Security should repeat the bundle review, the unauthenticated access test and the resolver checks whenever the team moves between release lines or changes the entry point configuration. Plugin owners should confirm that their own frontend packages still pass the same checks, since third-party code is outside the platform team's direct review.
Questions teams ask before protecting the frontend bundle
How much effort does splitting the Backstage frontend bundle take?
The effort depends on how many plugins, custom routes and sign-in flows your Backstage app has, and on how many frontend modules already load code that a signed-out visitor should never receive. Start by listing the routes and plugin components that must stay hidden from anonymous users, then check the current Backstage authentication documentation and the experimental feature notes for the version you run. Recurring work includes retesting the split after each upgrade, because a new release line can change how frontend code is assembled. Ask any partner to break the estimate into inventory, configuration, testing and upgrade support so you can see which parts are one-time and which repeat.
Is an authenticating proxy cheaper to run than the public entry point?
Often yes, for a single identity provider and a modest portal, because an authenticating proxy in front of the whole app stops unauthenticated requests before any JavaScript is served. The Backstage authentication documentation lists proxy-based providers such as Cloudflare Access, AWS ALB and Google IAP. The running cost is the proxy, its policy rules and its own patching, which your platform team may already operate. The public entry point keeps sign-in inside Backstage but adds a bundle split that you must maintain across upgrades. Compare the two options on who operates the proxy, whether your network already routes users through one, and how many sign-in paths you must protect.
Is the experimental Backstage public entry point safe for production?
Treat it as a decision to test, not a default. The feature is experimental, so confirm its status, known limits and open issues in the Backstage release notes for your exact version before you enable it. Verify that no protected route, API response or plugin component reaches an anonymous visitor. Check what a downloaded bundle reveals if the split is incomplete: anything placed in frontend configuration, plugin names, route paths and API base URLs can be read by anyone who loads the page. Backstage backports high and critical vulnerability fixes to releases from the last six months where feasible, so run a supported release line and retest the split at every version bump.
What does splitting the frontend bundle need from our internal team?
Your team needs an owner for the Backstage app repository who can read its frontend code, someone who understands your sign-in provider and resolver setup, and a platform or security owner who approves what may be visible to anonymous users. Expect to provide the current app-config files, the list of installed plugins and routes, identity provider settings, and a staging environment that matches production. Your organization decides which pages are visible without sign-in, and that decision should be recorded before implementation starts. Agree on who reviews the bundle output and who approves the change before it reaches production.
Can our own engineers protect the Backstage frontend bundle in-house?
Yes, if your engineers already maintain a Backstage app and have time for a frontend change plus regression testing. The work is mostly code and configuration inside your repository, and it does not depend on a proprietary product. The harder part is ongoing: each upgrade may change how plugin frontends load, so someone must repeat the verification. Teams without frontend experience or without a staging environment often find the first split takes longer than they planned. DeployOpen can plan, implement, verify and document this work under a fixed scope agreed in writing before work starts, and ongoing upgrade support is available as a retainer.
How long does verification take as the plugin count grows?
Verification effort grows with the number of plugins and routes that a signed-out visitor could reach, because each one needs a check that it stays hidden, fails safely and does not expose data through API calls or bundle chunks. Count the items in your inventory, then add plugins that expose their own backend routes or unauthenticated endpoints. Testing should cover anonymous browsing, direct URL access, deep links, sign-out, session expiry and a scan of the bundle for secrets or internal values. Ask for the test matrix in any proposal so you can see how the plugin count changes the effort and the schedule.
What should a quote for frontend bundle protection include?
A useful quote states the scope in writing: the inventory of routes and plugins, the target sign-in model, the environments covered, the verification matrix and the evidence delivered. It should separate one-time work, such as the inventory, the split, documentation and first verification, from recurring work, such as retesting after upgrades and patch cycles. Ask which items are excluded, such as identity provider changes or fixes to third-party plugins, and how those would be handled if they surface. Request the assumptions behind the effort, including the Backstage version and plugin count, and the change process after the scope is signed. DeployOpen does not publish a price list, so a quote follows from the written scope.
Limits to confirm in your environment before choosing this control
The public entry point is a frontend-hiding option with conditions attached, so the choice depends on facts about your installed version, identity setup, plugins, delivery path and audit requirements. Each card below is a question to answer with the Backstage project or with your own tests before you commit to this control.
Experimental status and supported packages
Confirm whether the public entry point is still marked experimental in the Backstage version you run, and which packages and plugins it supports. Check the release notes for your exact version, since the feature's status and package coverage can change between release lines. Ask whether any plugin you depend on falls outside the supported set, and whether the project commits to compatibility across upgrades. Treat anything unsupported as a reason to keep the bundle on the protected path.
Authentication providers that work with the proxy
Test which of your identity providers can sit behind an authenticating proxy in front of the whole app, including the sign-in callback path and session cookies. Some providers in the built-in list are designed for direct browser sign-in, so the proxy layer may need a different flow. Verify that every user who reaches the bundle resolves to the same identity your sign-in resolvers expect.
Frontend code shipped by third-party plugins
Inspect the built bundle from your actual plugin set, not only the core app. A community plugin may embed internal hostnames, feature flags, API paths, tenant identifiers or sample data that the core app does not expose. Ask whether removing the protected path changes what those plugins reveal, and whether each plugin's frontend can call backend routes that still require sign-in.
Caching and CDN treatment of the bundle
Confirm how your reverse proxy, CDN and browser caches store the JavaScript, source maps and HTML. A cache rule that serves a bundle without re-checking the session can expose it to users who should be signed out, while a rule that caches a protected response for one user can leak it to another. Test with a signed-out browser, an expired session and a shared cache in place.
Source maps and build artifacts
Check whether your build publishes source maps, build manifests or config snapshots alongside the bundle, and where your delivery pipeline copies them. Source maps often reveal more than minified code, including file paths and internal comments. Decide whether these artifacts sit behind the same access control as the bundle, and record that decision in your build configuration.
Access control required by compliance evidence
Ask your assessor or compliance lead whether they expect access to the portal front end to be enforced by a named control, such as the identity provider or a gateway, and how they will test it. A frontend-only split may not satisfy an access control requirement that auditors read as covering all application content. Capture the evidence you will show, such as a request log of unauthenticated attempts for the bundle path.
How DeployOpen scopes and delivers frontend protection for Backstage
DeployOpen plans, builds and hands over Backstage deployments inside infrastructure you control, including the decision on how the frontend bundle is exposed. We start from your threat model and sign-in design, agree a written scope, and deliver tested configuration with documentation your team can run after handover.
How we scope
- We review how your sign-in, reverse proxy and frontend hosting currently expose the JavaScript bundle to unauthenticated visitors.
- The written scope states whether the public entry point split, an authenticating proxy, or both will be implemented, with the reasons recorded.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support available as a retainer.
How we build
- We inventory which plugin routes, API paths and build-time values appear in the bundle, and classify each as public or restricted.
- We configure the frontend and backend split or the proxy authentication layer in a staging environment that mirrors production.
- We test unauthenticated requests against the bundle, static assets and API routes, and record the results as verification evidence.
How we hand over
- You receive the configuration, build pipeline changes and a written runbook covering how to add plugins without re-exposing internal routes.
- The documentation explains the trade-offs made, the remaining exposure and the checks your team should repeat after each Backstage upgrade.
- We walk your platform and security engineers through the controls so they can review and operate them without us.
How we support
- Retainer support can cover re-running bundle exposure checks after Backstage version bumps and new plugin installations.
- Upgrade work follows the Backstage upgrade path, with template changes reviewed against your customized frontend before rollout.
- Ask any provider to confirm which items sit in the written scope, who owns each control after handover, and how verification is repeated.
