Storybook, Backstage, GraphQL Playground: the developer tools you left on the public internet

Every modern team runs a stack of tools whose whole job is to make the codebase legible: a component explorer so designers can see every UI piece, a developer portal that catalogs every service, an interactive console for poking at the API. They're brilliant for the team. They're a guided tour for an outsider, because legibility for your developers is legibility for an attacker too.

The pattern that exposes them is always the same. The tool gets wired into the build, or deployed to the same host as the app, "for staging," and then it ships to production and nobody turns it off. It sits at a predictable path, answers an anonymous request, and explains your internals to whoever finds it. Here are four the scanner checks for.

Storybook: a catalog of every component you built

Storybook renders your UI components in isolation so the team can develop and review them. Left public (commonly at /iframe.html, its internal render frame), it's a browsable index of your entire front end: every component, every state, the internal names, often draft and admin-only UI that isn't linked anywhere on the live site. It's not a direct breach, but it's a precise map of how your app is built and what UI exists that the public navigation never reveals, exactly the kind of pre-work that makes the next step faster.

Backstage: your internal developer portal

Backstage (Spotify's open-source developer portal) is the catalog of your whole engineering org: every service, who owns it, how it's deployed, the internal docs, the dependency graph. Exposed at /catalog, it's the single richest recon document on this list. An attacker doesn't have to map your architecture; you've published it, organized and searchable. Service names, ownership, internal URLs, tech choices, all of it laid out for them. This one's rated high for a reason.

GraphQL Playground and GraphiQL: an interactive line to your API

These are interactive consoles for a GraphQL API, served at /graphql, /playground, or /graphiql. The page itself is the finding: a public GraphQL IDE means anyone can sit at a console wired to your API and, via introspection, read the entire schema, every type, every query, every mutation, including the internal and undocumented operations you assumed nobody knew about. From there it's a short hop to probing what those operations return without auth. The scanner flags the presence of the console page with a passive GET; it does not send an introspection query or any GraphQL operation, that would cross from reading what you serve into actively interrogating your API. The exposed IDE is signal enough.

The fix: these are internal tools, so keep them internal

None of these belongs on the public internet in production. The fix isn't to harden them, it's to make sure the world can't reach them.

# Storybook built and deployed alongside the app
# Backstage on the public app host
# GraphQL Playground left enabled in production config

Don't deploy Storybook to production at all, or if you must host it, put it behind your SSO. Bind Backstage to your internal network or VPN and require authentication. Disable the GraphQL IDE and schema introspection in your production config, the team uses them in development, where they belong. The through-line: a tool built for your developers should only be reachable by your developers.

Reading it from outside

Whether each of these answers an anonymous request is something a stranger settles by appending a known path, and that's exactly what SurfaceCheckr does, from outside, with no credentials. Each probe is gated on the tool's own distinctive markup, Storybook's render-frame markers, Backstage's config script, the Playground/GraphiQL init code, so it fires on the real tool, not on a site that merely mentions one. For the GraphQL consoles, it confirms the IDE page is served and stops there, no introspection query, no API call. It reads what the page reveals about itself and reports it. These tools are wonderful when they're behind your front door; the check is simply whether you left the door open. If you want the broader class, the infra dashboards in the same situation and Swagger UI handing over your API map are the close cousins.