Storybook static build exposure limits without external authentication

Answer

With no external authentication, a Storybook static build is public by default. No mainstream static host provides zero-configuration private access for an arbitrary static site without a configuration step, and dev server host binding cannot be relied on for consistent network isolation across bundlers without per-project overrides. The minimal preview iframe sandbox that keeps core addon communication working is allow-scripts and allow-same-origin, which limits cross-origin leakage prevention.

Confirmed facts

• Storybook core does not ship authentication middleware, IP allowlisting, or a centralized iframe sandbox policy.
• A static build is a self-contained set of HTML/JS/CSS assets. Its exposure is exactly the visibility of the hosting platform and URL discoverability.
• Without a reverse proxy, VPN, or private bucket policy, any static host that serves the build publicly makes every story, source snippet and design token reachable by anyone with the URL. Storybook does not add access control to the static output.
• Preview iframe sandbox attributes are configurable per project via Storybook configuration, but there is no centrally enforced default. Isolation guarantees depend on project-specific settings.
• Storybook does not obscure source code in the static build; design tokens and component source are shipped to the browser.

Likely explanation

• No mainstream static hosting platform provides true zero-configuration private access for Storybook static builds without adding a reverse proxy layer. Private access typically requires bucket privacy settings, signed URLs, password protection, or organization-level access controls that must be enabled per site.
• Dev server host binding is delegated to the underlying bundler and environment variables. Defaults differ between Vite and Webpack based Storybook versions and have changed over time, so binding exclusively to localhost is not consistently enforced across all supported bundlers without per-project configuration.
• Preserving addon communication in the preview iframe requires allow-scripts and allow-same-origin. allow-same-origin is needed for Storybook's internal messaging and addon APIs, which means the sandbox cannot fully prevent same-origin data access within the preview frame.
• The minimal practical sandbox that keeps core addon communication working is allow-scripts and allow-same-origin. Adding allow-forms, allow-popups or allow-modals is project dependent and increases exposure.

Steps needed for this case

1. Hosting exposure check
2. Confirm the hosting platform documentation for private site options and verify whether private access requires configuration beyond default public serving.
3. Treat the static build as public by default unless a private storage or access control is explicitly configured.
4. Dev server binding verification
5. Check the Storybook version and the underlying dev server type in the project to determine which host binding environment variables apply.
6. Run the dev server and inspect listening addresses with OS network tools to confirm binding is limited to 127.0.0.1 and not 0.0.0.0.
7. Do not rely on defaults for network isolation.
8. Preview iframe sandbox verification
9. Inspect the built static output and the preview iframe attributes in the browser devtools to verify which sandbox tokens are present.
10. Accept that allow-same-origin re-enables origin privileges and limits cross-origin leakage prevention; sandboxing cannot compensate for missing host-level access control.

One missing diagnostic detail that changes the recommendation: the Storybook version and dev server manager type in your project. Host binding environment variables and default values are version-sensitive and bundler-specific, so the exact variable names and safe values depend on that.