How to Share Files Securely on Public Wi-Fi: Real Threats and Real Defenses

At any given moment in any coffee shop with free Wi-Fi, there is a reasonable chance that at least one person on that network has tools capable of intercepting unencrypted traffic from every other device on the network. This is not a paranoid claim. ARP poisoning toolkits like Bettercap and Ettercap are freely available, require no specialized hardware, and can be deployed by anyone with a laptop in under ten minutes.

The most common response to this reality—"but the website uses HTTPS"—is partially correct and mostly insufficient. HTTPS protects against some attacks on public networks. It does not protect against all of them. And for file sharing specifically, the gap between "the connection is HTTPS" and "my files are actually private" is wide enough to drive a data breach through.

This guide explains the real attack surface on public Wi-Fi, which threats affect file sharing specifically, what protections work and which are theater, and what you actually need to do to share files securely from a coffee shop, airport, hotel, or any other network you don't control.

The Actual Threat Model on Public Wi-Fi

Before prescribing defenses, it is worth being precise about who the threat actors are on a public Wi-Fi network. There are three distinct categories, each with different capabilities and motivations.

Other users on the network range from entirely benign to opportunistic attackers using off-the-shelf tools like Wireshark, Bettercap, or mitmproxy. These are the most common threat actors on public Wi-Fi. They can perform attacks within the local network (ARP poisoning, passive sniffing on older unencrypted networks) but cannot generally break your encrypted TLS connections without a specific technical exploit.

The network operator controls the access point, DNS resolver, and routing. A malicious coffee shop owner (or an employee with access to the router) can perform DNS spoofing (returning false IP addresses for domains you query), inspect all HTTP traffic, log connection metadata, and inject content into HTTP pages. The network operator cannot break TLS encryption on HTTPS connections without obtaining fraudulent certificates, but they do not need to. A DNS redirect to a convincing phishing page is often enough.

Adversary-in-the-middle attackers with rogue access points set up networks designed to impersonate legitimate ones. These are more sophisticated attacks that require a physical presence near the target, but they can intercept traffic before TLS is established and are particularly effective against targets who connect automatically to any network with a familiar name.

ARP Poisoning: How Attackers Intercept Your Network Traffic

The most common active attack on shared Wi-Fi networks is ARP (Address Resolution Protocol) poisoning. Understanding how it works explains why "we're all on HTTPS" is not full protection.

ARP is a protocol used by devices to map IP addresses to MAC (hardware) addresses on a local network. When your laptop wants to send traffic to the router, it broadcasts an ARP request: "Who has IP address 192.168.1.1?" The router responds: "That's MAC address AA:BB:CC:DD:EE:FF." Your laptop caches this mapping and uses it for subsequent traffic.

ARP has no authentication. Any device on the network can send an unsolicited ARP reply claiming to be any IP address. An attacker runs a tool like Bettercap that continuously sends false ARP replies to both your device and the router: "The router's IP is at my MAC address" and "Your IP is at my MAC address." Both your laptop and the router update their ARP caches with these false entries. Now all traffic you send to the router goes to the attacker's machine first. The attacker forwards it to the actual router, receives the response, and forwards it back to you. Neither end notices the interception.

If the traffic is encrypted (HTTPS, TLS-protected file uploads), the attacker can see the encrypted bytes but cannot read the content. If the traffic is unencrypted (HTTP, legacy file transfer protocols), the attacker reads everything. If the attacker performs SSL stripping (more on this below), even HTTPS connections become readable.

SSL Stripping: Why HTTPS Alone Is Not Enough

SSL stripping is a man-in-the-middle technique that downgrades an HTTPS connection to HTTP by intercepting the initial HTTP request before the browser can upgrade to HTTPS. It was first publicly demonstrated by researcher Moxie Marlinspike at Black Hat 2009 and remains relevant today for sites that do not use HSTS Preloading.

Here is how it works in a public Wi-Fi context with an ARP-poisoned connection:

1. You type fileshot.io in your browser. The browser first makes an HTTP request (not HTTPS) to see if the site will redirect.
2. The real server responds with a 301 redirect to https://fileshot.io. Normally your browser would follow this and establish an HTTPS connection.
3. The attacker's machine intercepts the redirect, strips the https://, and sends your browser an HTTP version of the page instead.
4. Your browser is now communicating with the attacker's machine over HTTP. The attacker maintains a separate HTTPS connection to the real server.
5. Everything you send—logins, file uploads, messages—passes through the attacker in plaintext.

The defense against SSL stripping is HTTP Strict Transport Security (HSTS) and ideally HSTS Preloading. HSTS is a header that tells browsers "only ever connect to this domain over HTTPS, even if you see an HTTP link." HSTS Preloading hardcodes the domain into browser source code so the HSTS policy applies even on the very first visit, before any HTTP request is made.

If the file sharing service you use enforces HSTS Preloading, SSL stripping attacks against it are ineffective because your browser will refuse to make the initial HTTP request that the attack depends on.

Evil Twin Attacks: The Fake Coffee Shop Wi-Fi

An evil twin attack is conceptually simpler than ARP poisoning but frequently more effective. The attacker sets up a Wi-Fi hotspot with the same SSID as the legitimate network—"Starbucks WiFi," "Airport_Free_WiFi," "HotelGuest"—and broadcasts it with a stronger signal than the real network. Devices that connect automatically to known networks will connect to the evil twin. New users connecting manually may not notice the difference.

Once connected to the evil twin, all your traffic flows through the attacker's equipment. The attacker has a normal internet connection (through their own mobile data, for example) that they forward your traffic to. From a user perspective, everything works normally. Files upload and download. Websites load. But everything passes through the attacker's machine.

The evil twin attack is effective even against HTTPS for a specific reason: if the attacker can perform SSL stripping (because you are not HSTS Preloaded to the target site), or if the attacker can present a fraudulent TLS certificate that your device trusts (possible if the attacker has installed a root CA on a corporate device they control, or if your browser has a misconfigured trust store), the attacker can decrypt your HTTPS traffic.

The practical defense against evil twin attacks is twofold. First, certificate pinning or HSTS Preloading prevents the attacker from presenting a fraudulent certificate for major sites your browser already knows. Second, and more importantly for file content, zero-knowledge encryption ensures that even if the TLS connection is compromised, the attacker receives only encrypted ciphertext. The file encryption happens in your browser before transmission, so intercepting the transmission yields nothing useful.

DNS Spoofing on Public Networks

DNS spoofing (also called DNS cache poisoning in some contexts, though the mechanisms differ) allows an attacker who controls the DNS resolver—typically the network operator, or an attacker using ARP poisoning to intercept DNS queries—to return false IP addresses for domains you query.

When you type fileshot.io, your device asks the DNS resolver "what is the IP address for fileshot.io?" A compromised resolver can answer with the attacker's server IP instead of the legitimate one. Your browser then connects to the attacker's server. If the attacker has a TLS certificate for their domain (but NOT for fileshot.io), your browser will warn you about a certificate mismatch. If users ignore this warning (common on public networks where weirdness is expected), or if the attacker has somehow obtained a fraudulent certificate for fileshot.io, the attack succeeds.

The defense layer here is DNS over HTTPS (DoH) or DNS over TLS (DoT), both of which encrypt DNS queries so that the network operator and other users on the network cannot intercept or spoof them. Modern browsers like Firefox and Chrome support DoH by default or with minimal configuration. Enabling encrypted DNS on public Wi-Fi prevents DNS-based redirection attacks.

What VPNs Protect (and What They Don't)

A VPN (Virtual Private Network) tunnels all your network traffic through an encrypted connection to a VPN server before it reaches the internet. This defends effectively against most public Wi-Fi attacks: ARP poisoning attackers see only encrypted VPN tunnel traffic, evil twin operators see only encrypted tunnel traffic, DNS spoofing is bypassed because DNS queries go through the VPN tunnel, and the network operator cannot inspect your traffic.

VPNs are a strong layer of network-level protection on public Wi-Fi. But they have important limitations for file sharing:

The VPN server is a trust boundary. A VPN shifts the point of trust from the public network to the VPN provider. Your files are decrypted at the VPN server before being forwarded to the file sharing service. If the VPN provider logs traffic, cooperates with surveillance programs, or is itself compromised, your files are exposed. Free VPN services are particularly suspect—many are operated by entities that monetize user data as part of their business model.

VPNs do not protect file content. A VPN protects the channel (the connection between your device and the VPN server). It does not encrypt the files themselves. If the file sharing service you use transmits files in a format that the service's servers can read (i.e., the service holds the decryption keys), your files are readable by the service even when transferred through a VPN.

The strongest combination is a reputable VPN for channel protection plus client-side file encryption (zero-knowledge) so that even if the VPN is compromised the intercepted files are unreadable.

Why Zero-Knowledge Encryption Is the Real Defense

The common thread in all of the attacks discussed above—ARP poisoning, SSL stripping, evil twin, DNS spoofing—is that they aim to intercept files in transit. The network-level defenses (HTTPS, HSTS, VPNs, DoH) aim to make that interception harder or impossible. But the architectural question is: what does the attacker get if interception succeeds despite all defenses?

With traditional file sharing services (including major platforms like WeTransfer, Google Drive on a network, or FTP), the attacker who successfully intercepts an upload gets the file in plaintext. They can read, copy, and exfiltrate it immediately.

With zero-knowledge encryption, the file is encrypted in your browser before it is uploaded. The upload that traverses the public Wi-Fi network is encrypted bytes—content that looks like random noise to any interceptor. An attacker who performs a perfect ARP-poisoned SSL-stripping evil twin attack and successfully intercepts your FileShot upload receives AES-256 encrypted ciphertext. They do not have the decryption key. The attack succeeds technically but yields nothing useful.

This is the correct mental model: network-level protections reduce the likelihood of interception; zero-knowledge encryption reduces the value of interception to zero. Both layers matter, but zero-knowledge encryption is the one that makes public Wi-Fi file sharing genuinely safe rather than merely reduced-risk.

Practical Security Checklist for Sharing Files on Public Wi-Fi

Here is a concrete checklist for any time you need to share files from a network you do not control:

Before Connecting

• Verify the network name with staff. Ask the coffee shop or hotel what their exact Wi-Fi SSID is. Evil twin networks often have slightly different names or use the same name as a common chain. "Starbucks WiFi 5G" is not the same as "Starbucks WiFi."
• Disable automatic Wi-Fi connections. Turn off the setting on your device that automatically connects to previously used networks. This prevents evil twin attacks that rely on your device connecting without prompting.
• Enable a reputable VPN before connecting. Configure your VPN to connect automatically when you join any network that is not your home or office network.

When Choosing a File Sharing Service

• Use zero-knowledge encrypted file sharing. Ensure that the service encrypts your files in the browser before upload. If the description says "server-side encryption" or "encrypted storage," the server holds the keys and network interception yields readable content. True zero-knowledge means client-side encryption with a key that never leaves your device.
• Check for HTTPS with HSTS. In your browser, look for the padlock icon and verify the connection is HTTPS. Check if the site appears in the HSTS Preload list at hstspreload.org for maximum SSL-stripping protection.
• Use password-protected links. Password-protected file sharing links add an authentication layer that prevents unauthorized parties from accessing the file even if the link is intercepted or forwarded.
• Set short expiration times. When sharing files on a public network, use the shortest expiration time that meets your needs. A file that expires in 2 hours cannot be accessed if the link is intercepted and the recipient delays until tomorrow.

During the Transfer

• Enable encrypted DNS. In Firefox: Settings → General → Network Settings → Enable DNS over HTTPS. In Chrome: Settings → Privacy and Security → Security → Use secure DNS. This prevents DNS spoofing attacks.
• Watch for browser certificate warnings. Any certificate warning on a public Wi-Fi network is a major red flag. Do not click through "Your connection is not private" warnings. This is a common indicator of an evil twin attack or SSL stripping in progress.
• Avoid sensitive file sharing on 2.4 GHz public networks. The 5 GHz band has shorter range, which means evil twin access points using 5 GHz must be physically closer to be effective. If you have the choice, prefer 5 GHz connections in high-risk environments.

The Specific Risks by File Type

Not all files carry the same risk if intercepted on public Wi-Fi. Understanding which file types create the most exposure helps prioritize protection.

High risk: Documents containing personal information (contracts, medical records, financial statements, tax documents), source code (exposes intellectual property and may contain API keys or credentials), credential files (SSH keys, TLS certificates, configuration files with passwords), and business presentations or proposals before they have been shared with the intended recipient.

Moderate risk: Photos and videos with metadata enabled (EXIF data can reveal location, time, and device information), PDFs with embedded metadata (author names, company names, revision history), and spreadsheets with formula fields that could reveal internal calculations or pricing models.

Lower risk: Files that are already public-domain or that you intend to share publicly, generic binary files with no meaningful content to an attacker, and files you would not mind the network operator or other users seeing.

For high-risk files, zero-knowledge encryption is non-negotiable on public Wi-Fi. For moderate-risk files, consider stripping metadata with a metadata scrubber before sharing, and use encrypted transfer regardless. For lower-risk files, standard HTTPS is sufficient, but zero-knowledge encryption adds no meaningful overhead if you use a service that provides it by default.

The Bottom Line

Public Wi-Fi is a genuinely risky environment for file sharing, but the risk is well-understood and entirely manageable with the right tools. The threat model is not science fiction: the attack tools are freely available, require minimal skill, and are used by real-world opportunists at the exact places where people work remotely.

The defenses layer naturally: a reputable VPN for channel protection, HTTPS with HSTS enforcement for transport security, encrypted DNS to prevent spoofing, and zero-knowledge file encryption so that any intercepted file is useless to the attacker. Password-protected links and short expiration windows add further friction for any attacker who does manage to capture a link.

The inconvenient truth is that "I used HTTPS" is not enough to protect sensitive files on a network you don't control. The convenient truth is that it doesn't take much more to be genuinely safe.

Share files securely from anywhere with zero-knowledge encryption. Upload your first encrypted file on FileShot — your files are encrypted in your browser before they leave your device, making public Wi-Fi file sharing safe by design.

---

Frequently Asked Questions

Is it safe to share files over public Wi-Fi if the website uses HTTPS?

HTTPS protects against passive sniffing and basic interception, but it does not protect against all public Wi-Fi threats. Evil twin attacks can intercept your traffic before TLS is established, and SSL stripping can downgrade your connection to HTTP if the site does not use HSTS Preloading. Even with valid HTTPS, DNS spoofing on the network can redirect you to a phishing site. Zero-knowledge encryption ensures that even if your connection is intercepted, the attacker receives only encrypted ciphertext they cannot read.

Does a VPN protect files shared over public Wi-Fi?

A VPN encrypts all traffic between your device and the VPN server, preventing the public network from seeing your traffic. However, a VPN does not protect the files themselves — it protects the channel. The strongest protection combines a VPN for network-level security with zero-knowledge encrypted file sharing, so even if the VPN connection is compromised the intercepted files remain unreadable.

What is an evil twin attack and how does it affect file sharing?

An evil twin attack is a rogue Wi-Fi access point with the same name as a legitimate network. Your device may connect to it automatically. Once connected, all your traffic flows through the attacker's equipment. Zero-knowledge encryption defeats this attack because even if the attacker intercepts your upload, they receive only encrypted ciphertext — not the file contents.

Can someone on the same public Wi-Fi network see what files I'm uploading?

On WPA2/WPA3 networks, direct interception by other users is difficult, but ARP poisoning can allow an attacker to intercept your traffic. If your transfers are HTTPS-only the attacker sees encrypted bytes. If you use zero-knowledge encryption, even a fully successful interception yields only ciphertext the attacker cannot decrypt without a key that exists only on your device.