Your Beta Product May Have Leaked Before Publish

Yadong Xie · August 23, 2026

A private beta that redirects you to a login page and shows no features looks protected. But before the redirect, the browser may have already downloaded the app shell, CSS, runtime configuration, and route-level JavaScript. If so, the visitor is locked out of the product but their device already has the code.

Many teams mistook the pain of reading large minified bundles for protection. With LLMs, that assumption no longer holds.

A Six-Step Exposure Chain

An observer may not need the beta URL in advance. When a team requests TLS certificates for names such as preview.example.com or beta.example.com, those names may appear in public Certificate Transparency (CT) logs.

CT exists to expose mistakenly or maliciously issued certificates. Its logs are public, append-only, and auditable, so anyone can inspect the domain names in them. Certificate Transparency: How CT Works

1. Discover the entry point: Find a likely beta subdomain in a CT log.
2. Visit the host: Request the public HTTPS endpoint.
3. Receive the product code: The server returns 200 index.html and starts sending application bundles.
4. Check the session: JavaScript reads the session or calls /whoami, but only after startup.
5. Redirect to login: With no session, client-side code navigates away.
6. Analyze what was delivered: The address bar changed, but an LLM can still read the bundles.

CT only makes the entry point easier to find. The leak is confidential code delivered before authentication. A wildcard certificate may not reveal every subdomain, but entry points can also surface through old links, DNS records, or asset inventories.

JavaScript Redirects Run Too Late

A common SPA startup sequence:

GET https://preview.example.com/
  → 200 index.html
  → download app.js, route chunks, CSS, and config.js
  → JavaScript calls /whoami
  → no session: window.location = "/login"

The leak starts at the 200. If the client can execute the redirect on the last line, it has already received and run application code.

A JavaScript redirect can't control access, because it runs after code reaches the browser. An HTTP redirect can happen before any page content is sent. MDN: Redirections in HTTP

Hidden menus, route guards, frontend feature flags, minification, and obfuscation can control what the interface displays, but they can't make delivered code secret again.

LLMs Change the Cost

LLMs don't break TLS or give anyone access to server-side code. They make delivered bytes much cheaper to understand.

Work that once meant tracing hundreds of chunks by hand can now run in batches:

• Recover pages from route tables and dynamic imports.
• Infer features from components, copy, and state machines.
• Reconstruct data contracts from schemas, API clients, and error codes.
• Reuse CSS, class names, and static assets to rebuild the interface.
• Generate mock APIs and test data with realistic distributions.

So assume any JavaScript available before login can be automatically parsed, explained, and reconstructed.

What Leaks

Risk comes in three levels:

1. Product intelligence: Unreleased pages, core objects, enterprise features, and product direction become visible.
2. Attack-surface intelligence: API paths, field shapes, admin entry points, feature flags, and error codes become easier to enumerate.
3. Authorization bypass: Only when the backend also trusts hidden buttons, client-side roles, or “secret” URLs.

Downloading frontend code doesn't automatically grant backend access. If every request validates the user, tenant, role, and target resource, a reconstructed frontend is only an empty shell. OWASP also requires authorization to be enforced server-side on every request. OWASP Authorization Cheat Sheet

Authenticate Before Delivery

If the beta must stay confidential, the login portal and protected app shouldn't be two routes in one SPA or share a build with every feature.

Separate them in three places:

1. Builds: The login bundle contains no product routes or unreleased features.
2. Resources: Product HTML, JavaScript, manifests, and route chunks are returned only after authentication.
3. Access policies: The CDN, gateway, or application server checks identity before sending protected resources.

login.example.com and app.example.com create no boundary if both reference the same public app.js.

Delivery should look like this:

GET /app
  → unauthenticated: 302 Location: https://login.example.com
  → authenticated:   200 Product App HTML

GET /assets/product-app-[hash].js
  → unauthenticated: 401 / 302
  → authenticated:   200 JavaScript

Details Teams Often Miss

• Keep the login portal minimal: It should handle login, MFA, account recovery, and OAuth callbacks and not preload product chunks.
• Protect every build artifact: index.html isn't enough if /assets/*, manifests, or route chunks stay public.
• Remove confidential features from the build: A high-confidentiality beta needs separate build variants. Runtime feature flags alone aren't enough.
• Make caching identity-aware: An incorrect CDN cache key must never make a private response public.
• Keep enforcing backend authorization: Frontend isolation protects product intelligence. Server-side authorization protects what users can actually do.

Don't publish source maps or put secrets, internal tokens, or trusted authorization logic in frontend code.

What Separate Delivery Cannot Do

A user with legitimate beta access can still analyze the product code. Anything that runs in their browser can't be kept completely secret from them.

Separate delivery reduces exposure by keeping unauthenticated users, search engines, and automated scanners from downloading beta code at scale. You still need API authorization, auditing, rate limits, anomaly detection, and tester governance.

A 60-Second Pre-Launch Check

Open a clean, unauthenticated browser and check:

• Does the server redirect the product request before returning HTML?
• Does the login page download any product chunks?
• Can known product assets be requested directly?
• Does the build contain unreleased routes or internal feature names?
• Are source maps, manifests, or preload lists public?
• Can the CDN cache private responses across users?
• Does every API validate identity, tenant, and resource permissions?
• Are you monitoring new CT certificates and abandoned test endpoints?