Your Beta Product May Have Leaked Before Login

August 23, 2026

Open a private beta and it quickly redirects you to a login page. Without an account, you cannot see any features. On the surface, the product looks protected.

But before the redirect, the browser may have already downloaded the app shell, CSS, runtime configuration, and route-level JavaScript. The login check stopped the visitor from using the product, but it did not stop their device from receiving the product code.

Large minified bundles used to be painful to understand. Many teams mistook that friction for protection. LLMs are making that assumption obsolete.

A Six-Step Exposure Chain

An observer may not even know the beta URL in advance. When a team requests TLS certificates for names such as preview.example.com, beta.example.com, or studio.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 recorded in certificates. Certificate Transparency: How CT Works

The entire chain takes six steps:

1. Discover the entry point: Find a likely beta subdomain in a CT log.
2. Visit the host: Request the publicly reachable HTTPS endpoint.
3. Receive the product code: The server returns 200 index.html and begins sending application bundles.
4. Check the session: Only after startup does JavaScript read the session or call /whoami.
5. Redirect to login: No session is found, so client-side code navigates away.
6. Analyze what was delivered: The address bar has moved, but the bundles remain available for LLM-assisted analysis.

CT only makes the entry point easier to discover. The real problem is that confidential code was delivered before authentication. A wildcard certificate may not reveal every concrete subdomain, but entry points can also surface through historical links, DNS records, or asset inventories.

The Root Cause: JavaScript Redirects Run Too Late

A common SPA startup sequence looks like this:

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 problem is not the final line. It is the 200 on the first line. If the client can execute the redirect, it has already received and run application code.

A JavaScript redirect is navigation, not access control. An HTTP redirect can happen before page content is sent; a JavaScript redirect can only run after code reaches the browser. MDN: Redirections in HTTP

Hidden menus, route guards, frontend feature flags, minification, and obfuscation all share the same limitation: they can control what the interface displays, but they cannot make delivered code secret again.

LLMs Change the Cost

LLMs do not break TLS or invent access to server-side code. They dramatically reduce the cost of understanding bytes that were already delivered.

What once required manually tracing hundreds of chunks can now be processed 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 realistically distributed test data.

The new security assumption should be:

Any JavaScript available before login can be automatically parsed, explained, and reconstructed.

What Actually Leaks?

There are three distinct levels of risk:

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: This occurs only when the backend also trusts hidden buttons, client-side roles, or “secret” URLs.

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

The Correct Boundary: Authenticate Before Delivery

If the beta itself must remain confidential, the login portal and protected app should not be two routes inside the same SPA, and they should not share a build containing every feature.

Real separation has three layers:

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

Domains alone are not a boundary. Creating login.example.com and app.example.com changes nothing if both still reference the same public app.js.

The desired delivery sequence is simple:

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

Five Details Teams Commonly Miss

• Keep the login portal minimal: It should handle login, MFA, account recovery, and OAuth callbacks—not preload product chunks.
• Protect every build artifact: Protecting index.html is insufficient if /assets/*, manifests, or route chunks remain public.
• Remove confidential features from the build: High-confidentiality betas need separate build variants, not only runtime feature flags.
• Make caching identity-aware: A private response must never become public because of an incorrect CDN cache key.
• Keep enforcing backend authorization: Frontend isolation protects product intelligence; server-side authorization protects real capabilities.

Do not publish source maps or place secrets, internal tokens, or trusted authorization logic in frontend code. Anything the browser must execute can ultimately be inspected by the browser operator.

What This Architecture Cannot Do

A user with legitimate beta access can still analyze the product code. If a feature must run in their browser, it cannot be kept completely secret from them.

Separate delivery reduces the exposure surface. It prevents unauthenticated internet users, search engines, and automated scanners from downloading beta code at scale. It does not replace API authorization, auditing, rate limits, anomaly detection, or tester governance.

A 60-Second Pre-Launch Check

Open a clean, unauthenticated browser and verify:

• 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 new CT certificates and abandoned test endpoints being monitored?