Posting from a coworking space: what a shared network actually exposes

A freelancer opens a laptop at a coworking space, connects to the house wifi, and pulls up a client’s social media dashboard. The login screen never appears, because the session from yesterday is still active. That moment, not a hypothetical hacker in a hoodie, is the actual scenario worth examining. What does sharing a network with strangers expose, and what does it not?

The scenario, stated precisely

This is a different problem from losing access when someone leaves a job. That scenario, a team losing access it should keep because a 2FA device walked out the door with a departing employee, is a real and separate risk, but it is not this one. This piece is the reverse: someone else potentially gaining access while the legitimate user is still logged in, on a network neither of them controls.

The coworking space’s router is, in the ordinary case, not the attacker. The operator has no reason to intercept a tenant’s social media session, and most coworking wifi is unremarkable infrastructure. The actual risk sits one layer down: on a shared network segment, other devices connected to the same access point can, under the right conditions, see traffic that was not encrypted before it left the laptop. The router is the setting, not the threat.

What a session token actually is, and why it is the thing worth protecting

Staying logged in without retyping a password on every page load works because the site issued a session token, typically stored as a cookie, the first time the login succeeded. The browser sends that token back with every subsequent request, and the server treats a valid token as proof the request came from the already authenticated user.

This is also exactly the mechanism behind session hijacking. MDN’s glossary defines it plainly: an attacker who obtains a copy of a valid session ID can take over that session and act as the logged-in user, without ever needing the password. The password was only ever required once, at login. After that, the token does the work. Anyone holding a copy of it, for as long as that session remains valid, can act with the same authority as the person who logged in. That is the entire mechanism. There is no second gate.

The part that is actually checkable: is the connection encrypted

The single condition that determines whether that token is exposed to anyone else on the network is whether the connection carrying it is encrypted. HTTPS encrypts the traffic between the browser and the site, so a token sent over an HTTPS connection is not readable in transit by another device sharing the same wifi network. A token sent over plain HTTP, by contrast, travels as readable text that anything positioned to observe the local network segment can read.

Two specific mechanisms push a browser toward the encrypted version of that choice rather than leaving it up to chance. The first is the Strict-Transport-Security header, documented by MDN, which a site sends once and which then instructs the browser to only ever connect to that domain over HTTPS from then on, including on visits where the user typed or clicked a plain http address. The second is the Secure attribute on a cookie, covered in MDN’s guide to using HTTP cookies, which tells the browser never to send that particular cookie over an unencrypted HTTP connection in the first place, regardless of what a link or address bar says. Between the two, a site that sets both is telling the browser to refuse the unencrypted path entirely, for the connection and for the credential.

What the browser already does without the user doing anything

Some of this protection no longer depends on the site getting its own configuration right, because the browser itself has moved. In an August 2023 post titled “Towards HTTPS by default,” the Chromium team described Chrome automatically upgrading http:// navigations to https://, even in cases where a link explicitly points to the unencrypted address. Instead of trying the plain connection first and hoping for a redirect, the browser now defaults to attempting the secure version before anything is sent.

That shift is a large part of why the exposure window on this specific scenario has narrowed over the last several years. It used to be reasonable to worry that a stray unencrypted link, a bookmark saved years ago, or a typed address without the “s” would quietly send a session token over plain HTTP. A browser that resists making that connection in the first place closes off a meaningful share of that risk before the user does anything at all.

What this does not establish is anything about a specific social platform’s own server behavior. This is a browser-level protection that applies broadly to how Chrome and similar browsers handle navigation, not a claim about how any named platform configures its own session cookies or enforces HTTPS on its servers. No page from any specific platform was verified for this piece, so none is cited as if it had been.

A one-minute check before logging into a client account on a new network

  • Look at the address bar on the actual page where credentials or an active session are being used, the dashboard or login screen itself, not just the coworking space’s homepage or marketing pages. Confirm it shows https and the padlock indicator there specifically.
  • Do not treat the coworking wifi’s own captive portal login page as evidence of anything. Many captive portals serve their own sign-in page over plain HTTP by design, a separate, long-known tradeoff in how that technology works, and it is a completely different connection from the one going to the social platform. A padlock missing on the wifi splash page says nothing about the platform’s session.
  • If the platform supports it, a hardware security key or an authenticator app adds a second factor that a stolen session token alone cannot bypass, provided that factor is required again and the session was not already sitting open and authenticated. This only helps at the point of a new login; it does not retroactively protect a session that is already active.
  • Log out explicitly, rather than just closing the tab, on any shared or borrowed device. A session left open on a device that is not the user’s own is a larger and more direct exposure than anything about the network it was connected to.

What a VPN changes and what it does not

A VPN encrypts the traffic between the device and the VPN provider’s own server. That closes the specific local-network interception scenario at the center of this piece: another device on the same coworking wifi segment can no longer read what is being sent, because the encrypted tunnel to the VPN server replaces the plain connection to the local network.

What it does not do is change whether the destination site itself uses HTTPS end to end between the VPN server and the platform’s own servers, and it does not protect a session token that is already stored insecurely on the device, or a session left logged in and unattended. A VPN moves where the exposure could occur, it does not eliminate the need for the platform’s own connection to be encrypted. No specific VPN product is named or recommended here, since that choice sits outside what this piece is trying to establish.

Get the account-sharing habits right too

A team that has this network question sorted out but is still emailing a raw password around has closed the smaller door and left the larger one open. See sharing brand account access without sharing a password for the credential side of the same problem, and what browser extensions can see on a team laptop for the device side of it.

FAQ

Can someone on the same coworking wifi steal my social media login just by being on the network?

Only if the connection between the browser and the platform is not encrypted end to end. Being on the same network is not, by itself, sufficient. That is why the padlock check on the actual login or dashboard page matters more than the identity or reputation of the network. Modern browsers also push connections toward HTTPS by default, per the Chromium team’s own 2023 documentation of that shift, which narrows this window before the user checks anything.

Does the coworking space’s own wifi login page being unencrypted matter?

That captive portal page is a separate connection from the one going to the social platform, and an unencrypted portal page does not by itself expose the platform session. The two should not be treated as the same risk. Check the platform’s own login page for its own padlock rather than judging it by the network’s splash screen.

Is a VPN enough to make coworking wifi safe for posting to a client account?

A VPN addresses interception on the local network, which is the scenario this piece is about, but it is not a substitute for the platform itself using HTTPS end to end, and it does not protect a session that is already left open on an unattended device. It closes one specific door, not every door.

Sources

Scroll to Top