Coding on Public Wi-Fi: What's Actually at Risk (and How to Actually Protect Your Stack)

Hybrid work turned coffee shops, co-working spaces, and airport lounges into regular dev environments. You push a commit before boarding, SSH into a staging box from a conference hall, or pull up an internal dashboard on hotel Wi-Fi to check an overnight job. Most developers treat this as a non-issue — "everything's over HTTPS anyway" — but that assumption covers less of your actual workflow than it feels like it does.

A consumer VPN like Planet VPN closes exactly one part of this gap: it stops anyone else on the same access point from sitting between your laptop and the internet. That's genuinely useful on a network you don't control, but it's also the smallest part of the problem — most of what actually leaks on public Wi-Fi never touches the ISP or the access point at all.

What public Wi-Fi actually exposes

A public access point is, by definition, a network full of strangers on the same broadcast domain. On an open or poorly isolated network (plenty of café and hotel Wi-Fi still don't enable client isolation), anyone else connected can attempt ARP spoofing, run a rogue access point with the same SSID, or just sniff unencrypted traffic. That's the classic "coffee shop hacker" scenario — real, but not the part most developers actually get burned by.

TLS already handles the traffic you'd instinctively worry about: git push over HTTPS, your package manager, your browser tabs. The gap is everything that was configured assuming a trusted network in the first place, and then got carried onto an untrusted one without anyone re-checking the assumption.

The more common failure is what's running on your machine, misconfigured for a trusted network and now sitting on an untrusted one:

• Dev servers bound to 0.0.0.0 instead of localhost — npm run dev, a Flask debug server, a Docker container with a published port — are reachable by anyone else on the same subnet, not just you.
• Internal admin panels or database GUIs (Adminer, pgAdmin, an internal metrics dashboard) that skip auth "because it's only used internally" are now internal to a hotel network, not your office.
• SSH with password auth instead of keys is brute-forceable if it's exposed; SSH with keys is fine even on a hostile network — this one genuinely isn't a Wi-Fi problem.
• API keys and tokens in plaintext headers or .env files synced over an unencrypted side channel (some IDE sync and remote-dev-tunnel setups still do this) are readable to anyone positioned on the network.
• Auto-join and MAC address persistence mean your laptop broadcasts probe requests for every network it remembers, which is a minor tracking/fingerprinting exposure most people never think about.

Notice that a VPN addresses exactly one bullet indirectly (it re-encrypts the hop to the access point) and none of the others directly — a leaky dev server is still leaky inside an encrypted tunnel if the tunnel just relays it further downstream.

A practical hardening checklist

None of this requires exotic tooling — it's mostly configuration you already have access to:

1. Bind local dev servers to 127.0.0.1, not 0.0.0.0, unless you specifically need LAN access — and if you do, use an SSH tunnel or a service like ngrok/Tailscale Funnel instead of opening the port to the whole network.
2. Kill password auth on SSH entirely; key-based auth (ideally with a hardware key or ssh-agent + passphrase) removes the brute-force vector completely, on any network.
3. Put auth in front of every internal tool, even "temporary" ones — a five-minute Basic Auth wrapper is cheaper than a leaked staging database.
4. Route your traffic through a VPN with a kill switch when working from a network you don't control, specifically so a mid-git push connection drop doesn't silently fall back to the raw, unencrypted connection.
5. Check your DNS isn't leaking to a captive-portal resolver — some hotel and airport networks intercept DNS regardless of your settings, which a VPN with its own resolver sidesteps but a plain HTTPS connection doesn't.
6. Turn off Wi-Fi auto-join for networks you don't trust long-term, and forget saved networks you're not going back to.
7. Audit what's actually listening before you leave your trusted network — lsof -i -P | grep LISTEN or netstat -tulpn takes ten seconds and tells you exactly what a stranger on the same access point could try to reach.

The honest framing: a VPN is one layer in a stack, useful for the specific threat of a hostile local network, and worth having active by default when you're not on infrastructure you control. It's not a substitute for binding your dev server correctly or putting auth on your admin panel — those fixes work whether you're tunneling or not, and they're the ones that actually stop the incidents that make it into a postmortem.