Expo dev server tunnel missing authentication boundary for local development URLs

Short answer

Yes — as of current Expo CLI releases, expo start --tunnel creates a publicly reachable ngrok URL with no authentication challenge, no allowlist, and no prompt. Anyone who obtains the link can fetch your JavaScript bundle and hit Metro's endpoints. This is confirmed behavior, not a misconfiguration on your side. There is no built-in --tunnel-auth flag; access control has to come from a layer you add yourself.

What's confirmed vs. likely

Confirmed: the tunnel proxies your local Metro bundler through ngrok's free-tier edge, which serves requests without credentials. Metro itself has no auth middleware enabled by default. The bundle served over the tunnel contains whatever your app embeds — including any hardcoded API keys or non-secret-flagged environment variables.

Likely explanation: the tunnel exists for frictionless device testing (a teammate scans a QR code and the app loads). Adding an auth handshake would break that flow for the Expo Go client, which expects to fetch the manifest and bundle directly. So the CLI optimizes for the common case and leaves hardening to you.

What to do about it

1. Treat the tunnel URL as a secret. Share it only over authenticated channels, and stop the session (Ctrl+C) when done — the URL dies with the process.
2. Prefer LAN mode when possible. npx expo start (default) or --lan keeps the bundler behind your network perimeter. Only use --tunnel when NAT or firewall rules genuinely require it.
3. Audit your bundle for secrets. Anything reachable via process.env.EXPO_PUBLIC_* is shipped to clients by design. Move real secrets behind a backend; never rely on tunnel obscurity.
4. Add auth at the ngrok layer if you need it. Running your own ngrok agent (ngrok http 8081) with OAuth or basic-auth options on a paid plan gives you a gated tunnel, though this may break Expo Go's manifest fetch — verify with your actual client flow.

Verifying the exposure

Confirm the behavior on your own setup before assuming mitigations work:

npx expo start --tunnel
# From a phone on cellular (off your LAN), open the tunnel URL in a browser.
# If the bundle/manifest loads with no 401/403, the endpoint is open.

You can also check the response headers with curl -I https://<your-tunnel-url> — an open tunnel returns 200 with no WWW-Authenticate challenge.

On the open questions

An opt-in auth mode (none/token/team) would be a reasonable CLI feature request, and short-lived signed URLs are technically feasible at the proxy layer. But there is no documented migration path for previously shared tunnel URLs — the only retroactive control is that tunnel URLs are ephemeral: once the session ends, the link is dead. If a URL leaked during an active session, restart the server to get a fresh one.

Note: ngrok's feature tiers and Expo CLI flags change over time — verify current options against the installed CLI's --help output before relying on any specific flag.