Why Public Sharing Links Are Dangerous
By Simon Themiot - freelance cybersecurity consultant. Published May 22, 2026.
Summary
- An "anyone with the link" URL is a bearer access token: whoever obtains it receives the associated permissions unless an extra password or authentication step applies.
- Links can leak through history, extensions, synchronisation, application logs, screenshots, wrong recipients, or accidental indexing.
#fragments, however, are not sent in ordinary HTTP requests. - The alternative: E2E encryption with key in URL fragment (not transmitted to server) + password + expiration.
Table of contents
1. How a public sharing link works
When you create an "anyone with the link" link on Google Drive, Dropbox, or OneDrive, the service generates a URL containing a random unique identifier (token). This token is the only "secret" protecting access. There is no authentication, no identity verification, no password. Security relies entirely on the URL's unpredictability.
This is a capability-link model, not merely "security through obscurity". It can suit a low-sensitivity one-off share when the token has sufficient entropy, its scope and lifetime are limited, and its distribution channel is controlled.
2. Link leak vectors
Browser history
The URL is recorded in local history. If the computer is shared (open space workstation, family computer), anyone can find the link. Info-stealer malware systematically exfiltrates browsing history.
Corporate proxy logs
A proxy, CASB, or endpoint agent may log URLs depending on configuration. An ordinary HTTP proxy never receives the fragment after #; a browser agent or privileged extension may nevertheless see the full URL displayed locally.
Browser extensions
Chrome/Firefox extensions with "access all sites" permission see every URL you visit. Several popular extensions have been caught exfiltrating browsing history to third-party servers.
HTTP Referer header
The Referer header may reveal all or part of the source page URL depending on Referrer-Policy and context. Browsers do not include the fragment. A strict policy such as no-referrer reduces this leak channel for tokens placed in paths or queries.
Accidental copy-paste
The link is pasted in a public Slack/Teams channel instead of the intended private message, or emailed to the wrong recipient. Once disclosed, it may remain active until an expiry or revocation invalidates it.
3. Real incidents
- Wrong channel: a link intended for a private message is posted in a group channel or broadly accessible ticket.
- Compromised account: message or email history exposes every link that remains active.
- Excessive logging: a token placed in the path or query ends up in application logs, analytics, or diagnostic captures.
4. The secure model: key in the fragment
The HTTP specification defines that the "fragment" part of a URL (everything after the # character) is never transmitted to the server. It remains exclusively in the client's browser.
PrivCloud uses this mechanism for E2E links: the decryption key is placed in the fragment and is not sent in the HTTP request. A storage compromise therefore does not yield plaintext content, provided the key, browser, and delivered JavaScript are not compromised.
This model does not eliminate full-link leaks: history, an extension, or the recipient can still reveal the key. The optional password adds an independent server-side access gate; it should be strong and sent separately.
Defense in depth
- Key in the fragment (not transmitted to server)
- Additional password (not present in URL)
- Automatic expiration (link stops working)
- Download limit (disables link after X accesses)
5. FAQ
Google Drive offers the "restricted" option - is it sufficient?
The "restricted" option (only people added) is much better than "anyone with the link". But it is not E2E: the model does not remove Google's technical ability to access content. It also requires the recipient to have a Google account, which may not suit clients, suppliers, or candidates.
Can you know if a public link has been accessed by a third party?
Visibility depends on the service and plan. For an anonymous visitor, a log may record access without providing a reliable identity. Verify the audit data exposed to administrators before using a public link for sensitive data.
Do URL shorteners add additional risk?
Yes. A shortener adds an intermediary that sees each request and becomes another dependency. Depending on identifier length and randomness, a short URL may also be easier to enumerate. Do not use shortening to hide a link that is itself an access secret.
Related articles
Share without exposing
PrivCloud can generate E2E links whose key is not sent to the server when that option is enabled. Add a strong password and expiry to reduce exposure further. The recipient needs no account.
This article is provided for informational purposes and does not constitute legal advice. Last updated: July 14, 2026.