DEV Community

gokul
gokul

Posted on

Anyone with your tunnel URL can hit your dev machine — the attack surface nobody mentions

#webdev #programming #devops #security

You start your dev server, open a tunnel to show a teammate your
progress, and get a public URL. You paste it in Slack. They click it,
see the app, great. Meeting ends.

 Who else has that URL?

 Your teammate, obviously. Anyone who scrolls back in that channel. Any
Enter fullscreen mode Exit fullscreen mode

bot that scrapes the link. Anyone who guesses the subdomain if it's a
common word. And here's the uncomfortable part: that URL doesn't point
to a hardened production deployment. It points to your laptop. To the
branch you're halfway through breaking. To debug mode, with stack traces
on, maybe with an admin panel that skips auth in development.

 ## Public dev URLs are real URLs

 We treat tunnel URLs as disposable, but for the hours they're live
Enter fullscreen mode Exit fullscreen mode

they're genuine endpoints on the public internet, fronting machines that
were never meant to face it.

 The failure modes aren't exotic:

 * Debug endpoints leaking environment variables through an error page
 * Admin panels that "temporarily" bypass login
 * Webhook receivers that happily process forged payloads from anyone
Enter fullscreen mode Exit fullscreen mode

who finds the URL
* API keys in a .env file one directory-traversal bug away from
disclosure
* The tunnel you opened on Friday that's still running on Monday,
pointed at a branch that no longer exists

None of this needs a sophisticated attacker. It needs a URL, and URLs leak.

 ## What responsible tunnel hygiene looks like

 **Short-lived by default.** A tunnel should be something you open for
Enter fullscreen mode Exit fullscreen mode

a purpose and close when the purpose is done — not infrastructure that
accretes. If your tool ties URLs to expiring keys, use that. An expired
URL is a dead end for anyone who finds it later.

 **Expose one port, not your machine.** If the tunnel can serve your
Enter fullscreen mode Exit fullscreen mode

whole box, a config mistake becomes a much bigger mistake.

 **Gate it when it matters.** If you're showing a client something or
Enter fullscreen mode Exit fullscreen mode

testing against a third-party service for days, put the tunnel behind
sign-in at the edge, before traffic ever reaches your app. Your
application code shouldn't have to know it's being protected.

 **Scoped keys for AI agents.** If you're handing tunnel access to an
Enter fullscreen mode Exit fullscreen mode

AI coding agent — and more teams are every month — don't give it your
master credentials. Give it a key that can open exactly one tunnel, and
revoke it when the task ends. An agent with a permanent tunnel and a
master key is an intern with root access.

 ## The takeaway

 Whatever tool you use, the principle holds: a public URL is a real
Enter fullscreen mode Exit fullscreen mode

URL. Treat your dev machine like the internet can see it — because for
as long as that tunnel is open, it can.

 ---

 *Full disclosure: I work on [21tunnel](https://21tunnel.com), an
Enter fullscreen mode Exit fullscreen mode

open-source tunnel built around this model — scoped, short-lived keys,
cascade revoke, and edge auth that gates any tunnel behind Google
sign-in with zero code changes.*

Top comments (0)