Is Public WiFi Safe in 2026? What an Attacker Can Actually Steal

The advice to avoid public WiFi is a decade out of date, and the reason it is out of date matters more than the advice. Around 2010, sitting in a cafe with a packet capture running genuinely harvested credentials, because logins travelled over plaintext HTTP. A Firefox extension called Firesheep made it a one-click demonstration in 2010 and triggered the industry-wide move to HTTPS that followed.

That move worked. Chrome's own transparency reporting puts HTTPS at well over ninety percent of page loads on desktop, and HSTS preloading means a browser refuses to issue a plaintext request to a preloaded domain at all. The classic attack is dead on arrival for any site that did its homework.

What replaced it is a set of attacks that HTTPS was never designed to address.

The part that genuinely is solved

Associate with an open network, put the interface in monitor mode, and capture. On any modern site you get TLS records: an encrypted handshake, then opaque application data. No cookie, no password, no response body.

HSTS closes the one remaining crack. When you type bank.com into the address bar with no scheme, the browser's default is a plaintext HTTP request that an on-path attacker can intercept before the redirect to HTTPS happens — the sslstrip technique. A domain on the HSTS preload list, compiled into the browser binary, never gets that first plaintext request. You can check any domain's status:

chrome://net-internals/#hsts   → query a domain's HSTS/preload state

Enabling HTTPS-only mode removes the gap for everything else. In Chrome: Settings → Privacy and security → Security → "Always use secure connections". In Firefox: Settings → Privacy & Security → HTTPS-Only Mode → "Enable HTTPS-Only Mode in all windows". The browser then upgrades every navigation and shows an interstitial rather than silently falling back.

What still leaks when every byte is encrypted

TLS encrypts the payload. It does not encrypt the routing information needed to set up the connection.

TLS SNI is plaintext. The Server Name Indication extension in the ClientHello carries the hostname you are requesting, in the clear, because the server needs it to pick a certificate before encryption is established. Anyone on the path reads a precise list of hostnames: chase.com, healthportal.example, that-one-forum.net. Encrypted Client Hello (ECH) fixes it, but it requires support on the browser and the destination's infrastructure, so coverage in 2026 is partial.

DNS is plaintext by default. Before the TLS handshake there is a DNS lookup, and on a default configuration it goes to the DHCP-assigned resolver — the venue's router — unencrypted. That is a complete browsing log handed to the network operator. Fix it in one setting:

chrome://settings/security  → Use secure DNS → "With: Cloudflare (1.1.1.1)"

Firefox has the equivalent under Settings → Privacy & Security → DNS over HTTPS → Max Protection. On the OS level, Windows 11 supports DoH per-adapter under Settings → Network → Wi-Fi → Hardware properties → DNS server assignment.

Your device announces itself. mDNS and NetBIOS broadcasts carry your hostname, and hostnames are routinely vanshs-macbook-pro.local or DESKTOP-ACCOUNTING-04. On a shared LAN that is free reconnaissance. Rename the machine if the default gives away your name or role.

Traffic shape is visible. Volume, timing, and packet-size patterns survive encryption. This is academic for most threat models and genuinely relevant for a journalist or anyone whose presence on a site is the sensitive fact.

The WPA2 problem nobody mentions

"It's fine, the WiFi has a password." This is the most widely held misconception about public networks, and it is wrong in a specific, technical way.

WPA2-Personal derives its keys from a pre-shared key — the password on the chalkboard. Every client on that network uses the same PSK as input. The per-session keys come out of the four-way handshake that happens at association time, and the handshake is observable. Another guest who knows the password and captures your handshake — or who sends a deauthentication frame to force you to reconnect so they can capture it — can derive your pairwise transient key and decrypt your traffic.

A posted WPA2 password keeps out people on the pavement. It does nothing against the person two tables over who also bought a coffee.

WPA3-Personal replaces the PSK handshake with SAE (Simultaneous Authentication of Equals), a password-authenticated key exchange that produces a unique, forward-secret session key per client. The same password no longer yields the same key material, so a fellow guest cannot derive your keys even with a full capture. Enhanced Open / OWE does the same for networks with no password at all, giving unauthenticated but individually encrypted links.

The practical takeaway inverts the usual rule. A WPA3 or OWE network with no password is more private between clients than a WPA2 network with one. Check what you are on:

# Windows
netsh wlan show interfaces

# macOS
system_profiler SPAirPortDataType | grep -A2 "Current Network"

# Linux
nmcli -f IN-USE,SSID,SECURITY device wifi list

Look at the authentication or security field. WPA2-Personal means treat the LAN as hostile. WPA3-SAE or OWE means the link layer is doing real work.

Five attacks that still land

1. Rogue access points and the auto-join problem

Operating systems identify saved networks by SSID. Your laptop remembers Guest-WiFi from a hotel in another city and will happily associate with anything broadcasting that name, especially with a stronger signal. No exploit required — this is the documented behaviour of every WiFi stack.

Once associated, the operator controls DHCP, which means they control your DNS resolver and your default gateway. They cannot break TLS, but they can log every SNI hostname, serve a captive portal, and block or redirect anything that is not HSTS-protected.

Remove the attack surface by removing the saved profiles:

# Windows — list then delete
netsh wlan show profiles
netsh wlan delete profile name="Guest-WiFi"

# macOS
networksetup -removepreferredwirelessnetwork en0 "Guest-WiFi"

And turn off auto-join per network rather than globally: iOS under Settings → Wi-Fi → ⓘ → Auto-Join; Android under network details → Auto-connect; Windows by unchecking "Connect automatically" at connect time; macOS under System Settings → Network → Wi-Fi → Advanced, where you can untick Auto-Join per entry.

2. Captive-portal phishing

A captive portal is a page that intercepts your first request and asks for something before granting access. Legitimate ones ask for an email address, a room number, sometimes a card for paid access. That makes them the one context where a credential prompt from an unknown party is expected.

Two rules handle this. First, a captive portal should never need your email password, your Google account, or anything beyond a throwaway identifier — if it asks, close it. Second, portals are served over HTTP by design, so a browser certificate warning on a portal is not a false positive to click through; it is the interception you were worried about.

3. Plaintext-first navigation

Typing a bare hostname sends an HTTP request unless the domain is HSTS-preloaded or you have HTTPS-only mode on. The target set is narrow in 2026 but non-empty: small sites, regional services, internal tools, IoT admin pages. HTTPS-only mode covers it in one toggle.

4. Local service exposure

The default Windows prompt — "Do you want your PC to be discoverable?" — is the one that matters. Answering yes on a cafe network applies the Private profile, enabling network discovery and file and printer sharing to everyone on that LAN. Verify and correct it:

Settings → Network & internet → Wi-Fi → (network) → Network profile type → Public

On macOS, check System Settings → General → Sharing and confirm File Sharing, Screen Sharing, and Remote Login are off. On Linux, ss -tlnp lists anything listening; a development server bound to 0.0.0.0:3000 is reachable by every guest on the network.

5. Deauthentication and downgrade pressure

Management frames in WPA2 are unauthenticated, so an attacker can send deauth frames to knock you off a legitimate access point repeatedly. Nothing is stolen directly — the goal is to make the rogue AP the path of least resistance, or to force the handshake recapture described above. WPA3's Protected Management Frames (802.11w) is the fix, and it is mandatory in WPA3.

Attack-by-attack status table

That last row is the one to sit with.

The risk you will actually meet

Running the numbers on a typical cafe: the probability that a given customer is operating a rogue access point is low. The probability that at least one person can see your screen is close to one.

Public spaces put strangers behind you at eye level with your monitor for an hour at a stretch. Open tabs showing a bank balance, a client contract, an internal dashboard, or a half-written message are readable at two metres without any technical capability whatsoever — and unlike a network attack, this one leaves no trace and needs no setup. The mechanics and the realistic exposure window are covered in what someone can do with an unlocked browser tab.

The controls are unglamorous and effective. A privacy filter on the screen defeats off-axis viewing. A short screen-lock timeout — two minutes, not fifteen — covers the walk to the counter. For the specific case of a handful of sensitive tabs among many, a tab-level password gate like Locksy keeps those contents behind an unlock prompt while the rest of the window stays usable. Pick based on how often you leave the machine, not on how sophisticated the control sounds.

A pre-flight checklist

Run this once, and it holds for every network afterwards.

One-time setup

1. Chrome or Edge: enable "Always use secure connections" and secure DNS at chrome://settings/security.
2. Firefox: enable HTTPS-Only Mode and DNS-over-HTTPS Max Protection.
3. Turn on MAC address randomization — iOS "Private Wi-Fi Address", Android "Use randomized MAC", Windows "Use random hardware addresses".
4. Confirm file sharing, screen sharing, and remote login are off.
5. Delete stale saved network profiles, especially generic names like Guest, Free WiFi, and chain-venue SSIDs.
6. Set a screen-lock timeout you will actually tolerate and learn the lock shortcut.

Every time you connect

1. Check the security type with the command above; assume WPA2-PSK is readable by other guests.
2. Decline the "make this PC discoverable" prompt.
3. Treat the captive portal as untrusted — no real credentials, and no clicking through certificate warnings.
4. Delete the network profile when you leave if you do not plan to return.

Reserve for a trusted network

Password changes, MFA enrolment and recovery-code setup, and anything where a session hijack would be unrecoverable. Not because the cafe network will break TLS, but because the cost of being wrong about the network is asymmetric — and stolen session cookies travel further than stolen passwords, as session hijacking shows.

Where that leaves the question

Public WiFi in 2026 is safe for the thing people were originally told to fear and unsafe in ways that have nothing to do with cryptography. The transport is handled. What remains is your device trusting a network name it should not, a portal asking for something it should not get, a link layer whose shared password protects nothing between guests, and a screen that anyone can read.

Four of those five are fixed by settings you change once. The fifth needs a habit.