Why an 'unguessable' Dropbox or Google Drive link is not private

The share button is the part of cloud storage that everybody understands. You right-click the file, you pick 'get shareable link', a long random-looking URL gets copied to your clipboard, you paste it into an email or a Slack message, and the recipient clicks it and reads the file. The whole interaction takes maybe ten seconds. It feels, in a way that 'attach the file' does not, like the privacy-respecting choice: the file does not get emailed around, copies do not proliferate, the URL is long enough that nobody could guess it, and only the people you sent it to can open it.

That last clause is the one that breaks. 'Only the people you sent it to' is true for about as long as the link lives only in the inbox of the person you sent it to. The moment the URL appears anywhere a search-engine crawler can read it - a forum post, a Slack archive made public, a public GitHub README, a Jira ticket that escapes into a public instance, a blog draft that gets published, an email reply that gets quoted in a public ticket, a screenshot pasted into a tweet - the share link is, in every meaningful sense, public. Google indexes shared cloud URLs. The Wayback Machine snapshots them. Browser sync pushes them to devices that may not be yours. The Referer header leaks them to third-party scripts on whatever page you paste them into. And once a search engine has crawled the URL, the file is searchable - by URL fragment, by content, sometimes both - until the URL is revoked or the file is deleted.

This is not a theoretical concern. The record of incidents is long: Box.com's 2019 exposure of tens of thousands of corporate files via guessed and indexed share links, Microsoft's 2021 Power Apps disclosure of 38 million records through default share settings, periodic flare-ups of Google Docs and OneDrive documents appearing in Bing and Google indexes throughout 2014-2023, and the steady drumbeat of 'I accidentally made our company's strategy document public' stories that make the rounds on tech Twitter every few months. The pattern is always the same. The defence is to understand what 'anyone with the link' actually means and to choose the sharing model that matches the privacy you think you have.

What a share link actually is

The share link is a URL that combines two parts: an identifier for the file (or folder) and a token that grants access. The token is long - typically 128 to 192 bits of randomness, encoded as a URL-safe base64 string - which makes it effectively unguessable by brute force. Brute force is not the threat. The threat is that the entire URL, including the token, is a single unbroken string that travels together everywhere the link goes. There is no separate authentication step. There is no challenge-response. There is no per-user binding. The URL itself is the credential, and any system that has the URL can fetch the file.

This is by design. The point of the share link, from the cloud provider's perspective, is frictionless sharing - no account signup, no invite acceptance, no permission management. The property that makes it frictionless is the same property that makes it leak: a URL is the most trivially copyable, forwardable, loggable, and indexable artefact in computing. Once the URL has been generated, every system it passes through gets a copy. Every copy is equivalent to the original. There is no way to retract a copy.

The big consumer cloud-storage products differ slightly in their link shapes and defaults but agree on the underlying model. Google Drive's 'anyone with the link' shares a URL of the formdrive.google.com/file/d/<file-id>/view?usp=sharing; the file ID is itself the credential, no token query parameter needed. Dropbox uses dropbox.com/scl/fi/<hash>/<filename>?rlkey=<token>; the rlkey is the credential. OneDrive uses1drv.ms/<short-token> for shortened links or a longer SharePoint URL with an embedded resource ID. Box usesapp.box.com/s/<token>. In each case, the single URL string is everything - knowing it is sufficient to fetch the file.

Where the URL leaks: ten places worth knowing about

Once a share link exists, it can leak through any of about ten channels. Most of them are not the channel the person sharing the link was thinking about when they generated it.

Pasting into a public surface. The largest category by volume. The URL is pasted into a forum thread, a Reddit comment, a Stack Overflow answer, a public GitHub repository's README or issue tracker, a public Trello board, a Notion page set to public, a Google Doc set to 'anyone with the link', or a blog post. Search engines crawl all of these.

Workplace surfaces that turn out to be public. Slack channels in workspaces with public archives. Confluence wikis on self-hosted instances that are not behind a firewall. Jira tickets on Atlassian Cloud instances configured for public ticket visibility. Discord channels in public servers. The person pasting the link assumes the audience is the workspace; the actual audience includes whatever public archive or export job is running.

Email forwarding chains. The link is sent to a recipient who forwards the email to someone else, who forwards it again, who CCs a mailing list with a public archive (Apache, many open-source projects, government mailing lists). The archive becomes a public page containing the URL. Search engines crawl mailing-list archives aggressively.

Browser sync. Chrome, Edge, Firefox, and Safari all sync browser history across devices by default for signed-in users. The URL appears in the history of every device the user is signed in on - which, if the user is signed in on a work laptop, a personal laptop, a phone, and a tablet, is four devices. If any of those devices is shared, used by family members, or compromised, the URL is in the history.

Password managers and 'recent items' UI. Some password managers and browser-history UIs scrape the recent tabs and offer them as autofill suggestions or as recent-items widgets, which can surface the URL in screen-sharing contexts the user has not thought about (a presentation, a screencast, a debugging session).

The Referer header. When the share URL is opened in a browser and the destination page contains third-party scripts (analytics, fonts, ads), those scripts get the page URL via the Referer header. Cloud-storage providers have mostly tightened this with Referrer-Policy headers, but the URL still leaks if you forward it to a tool that lets you preview the file in a less-careful page wrapper. The same problem we covered in our piece on what your browser sends to every website applies to share URLs being opened by the recipient.

Screenshots. The share UI itself shows the URL in a copy field. A screenshot of the cloud-storage app intending to demonstrate something else can capture the URL. Image-search OCR makes the URL searchable as text within hours of the screenshot being posted publicly. The same applies to a screenshot of the browser address bar after the link is opened.

Corporate proxy and DLP logs. If the recipient opens the link on a corporate network, the URL appears in the proxy log, the firewall log, and any data-loss-prevention system that monitors outbound HTTPS. These logs are typically retained for months to years and are subject to whatever access controls the corporate IT department has set, which - for the log files themselves - are often weaker than the controls on the data they describe.

Wayback Machine snapshots. If the URL has appeared on a publicly indexed page, the Internet Archive's crawler may have snapshotted the page. The Wayback Machine's snapshot includes the page contents - which means the share URL, which means an attacker who finds the snapshot can still attempt to fetch the file (and will succeed if the link has not been revoked). Wayback Machine snapshots are durable: a URL in a snapshot from 2017 is still in the snapshot today.

The AI-tool surface. The newest leak channel and one of the largest in volume terms: someone pastes a share link into ChatGPT, Claude, or Gemini to ask the model a question about the file ('summarise this' or 'what's the deadline in this contract'). The model dutifully fetches the file - some AI tools do this automatically when given a URL, others require an explicit fetch step - and the URL, plus the file's contents, are now in that AI tool's chat-storage layer, subject to all the retention, legal-hold, and breach exposure we covered in our piece on what AI tools actually keep. The pattern is increasingly common in workplace settings, and the share-link semantics did not anticipate it.

The receipts: what has actually gone wrong

Three incidents are worth keeping in your head because they show the failure mode at industrial scale.

Box.com / Adversis, 2019. The security firm Adversis built a tool that combined subdomain enumeration of Box Enterprise tenants with brute-force guessing of share-link URL patterns, and they found that thousands of organisations had set their default sharing permission to 'people with the link can view' and had then generated share links following guessable subdomain conventions. The result was tens of thousands of exposed files belonging to Apple, Edelman, Schneider Electric, Discovery Channel, Herbalife, the City of Schaumburg Illinois, Amadeus, and dozens of other named organisations. The exposed files included passport scans, financial statements, intellectual property documents, customer lists, employee records, and at least one set of internal Edelman PR strategy documents discussing crisis-communication plans for named clients. The deeper lesson was that 'anyone with the link' becomes 'anyone' at the moment the link is guessable, indexed, or otherwise discoverable - and that an organisation-wide default setting determines exposure across every employee's sharing behaviour.

Microsoft Power Apps / UpGuard, 2021. UpGuard disclosed in August 2021 that Microsoft Power Apps portals defaulted to publicly exposing OData API endpoints unless developers explicitly enabled access controls. The result was 38 million records exposed across 47 organisations, including American Airlines (employee PII), Ford (employee data), JB Hunt (driver records), the New York City Municipal Transportation Authority (employee details and contact tracing), Maryland Department of Health (vaccination records), Indiana Department of Health, Microsoft itself (internal records), and a number of US states' contact-tracing systems. The 'share link' here was an API URL rather than a file URL, but the underlying failure mode is identical: a default-on sharing setting, no auth challenge, the assumption that obscure equals private. Microsoft changed the default to private in a platform update shortly after disclosure.

The long tail of indexed Docs. The other category that does not produce a single named incident but produces a steady flow of small ones is Google Docs, Sheets, and Slides set to 'anyone with the link' and then linked from a public page somewhere. Searches likesite:docs.google.com inurl:edit on Google have at various points surfaced internal strategy documents, financial models, employee handbooks, password lists, customer lists, and meeting notes from companies that did not intend any of it to be public. Google has, since around 2017, added noindex defaults to the consumer Docs surface that mitigate the worst of this, but the underlying property - that 'anyone with the link' becomes 'anyone' once the link appears on a crawled page - has not changed and continues to produce smaller-scale exposures.

What expiry and passwords actually buy you

Most cloud-storage providers now offer two additional sharing-link knobs: an expiry date and a password requirement. They are real defences and worth turning on, with caveats.

Expiry reduces the window during which a leaked URL is useful. A link that expires in 7 days is in Google's index for at most 7 days plus whatever cache lifetime applies, and the file becomes inaccessible at expiry even if the URL has been captured. The defensive posture this buys is durable: an attacker who finds the URL in a Wayback Machine snapshot from 2024 cannot use it in 2026. The trade-off is that the legitimate recipient also has 7 days, which is sometimes inconvenient.

Password protection adds an auth challenge that a crawler cannot pass, so the file itself does not get indexed (the URL may still appear in a search-engine cache as a 'this page requires a password' stub, which has its own information-leak properties but does not expose the file). The trade-off here is social: the password tends to be sent in the same channel as the link (often the same email or message), which means a leak of one is usually a leak of both. The defensible pattern is to send the password out-of-band - if the link is in an email, the password should be in a Signal message or read aloud over a phone call.

The remaining failure modes that expiry and passwords do not fix: anyone who has been given the link plus password can re-share both with no audit trail, a screenshot showing both works as an exposure vector, browser sync still puts the URL on other devices, and corporate proxy logs still capture both the URL and the password if either is sent over HTTP-equivalent UI (URL bar, form field).

Signed S3 URLs and the enterprise pattern

The enterprise version of the share link is the signed URL from a cloud-storage service (S3 presigned URLs, GCS signed URLs, Azure Blob SAS tokens). These have meaningfully better defaults along one axis: they expire by default, often in minutes or hours rather than indefinitely, and the signature ties the URL to specific HTTP methods (so a GET-signed URL cannot be used to overwrite the object). They are exactly as exposed along the other axes: a signed URL is still 'anyone who has the URL can fetch the file' for the duration the signature is valid, it still ends up in browser histories and analytics pixels if opened in a normal browser, and it can still be indexed by a crawler that finds it before it expires.

The defensible pattern for sensitive enterprise use combines three things: signed URLs with short expiry (minutes for downloads, single-digit hours at most), IP allowlisting on the bucket (so the signed URL only works from approved network ranges), and access logging on the bucket (so every fetch is recorded with timestamp, IP, and user-agent). Each layer catches a different failure mode. The combination is defensible. Any one layer in isolation - in particular, signed URLs on their own - is not meaningfully different from a consumer share link.

The actually private way to share a file

Pulling the above together: every link-based sharing model has the same shape of exposure, and the differences between them (expiry, password, signature) reduce the window or raise the bar but do not change the underlying 'whoever has the URL has the file' property. The categorical step up is named-recipient sharing.

Every major cloud-storage product offers it. The same UI that produces a share link also offers a 'share with specific people' option that requires the recipient to be logged in to a specific account and that does not generate a URL anyone else can use. On Google Drive it is the 'Share with people and groups' field; on Dropbox it is the 'Send' tab in the share dialog; on OneDrive it is the 'People you specify can view' permission; on Box it is the 'Invite people' flow. The trade-off is friction: the recipient needs an account on the same platform (a Google account, a Dropbox account, etc), and external-to-your-organisation recipients sometimes need to accept an invite before the first access works. The privacy property in exchange is qualitatively better - access is tied to an identity, the access can be revoked per identity, the access log shows which specific identity opened the file when, and there is no URL anyone could leak that would grant access to a different account.

For the cases where named sharing is not practical (a stranger you do not have an account for, a one-off transfer to a client you will not work with again), the second-best option is a link with all three of expiry (hours not days), password protection (sent through a different channel), and a low-stake copy of the file (redacted of anything you would not want in a searchable index later, since 'in a searchable index later' is a non-trivial probability for every share link). Our pieces on PDF redaction and what 'delete' really does cover the redaction and cleanup steps that make a share link safer to send in the first place.

The pattern, in one paragraph

'Anyone with the link' is the default-on, opt-out version of public sharing. It is sold as a privacy feature because the link is long; it is, in practice, a public-sharing feature with a slight delay before the link becomes findable. The right reflex is to treat every share link as a credential that will leak through at least one of the ten channels listed above within the lifetime of the file - because in aggregate, across enough share links, that is what happens - and to choose the sharing model accordingly. Named-recipient sharing for anything sensitive. Expiring, passworded, redacted links for one-off transfers to people without an account on the same platform. And, for the files that you would simply rather not put on a third-party cloud at all - the contracts, the IDs, the personal records, the things you would not want in an AI chat log either - the answer is the same answer we keep landing on in this blog: do the processing locally, and never upload the file in the first place. The same logic applies to online file converters and to AI tools you might be tempted to drop the file into. The cleanest privacy property is the one where the file does not leave the machine.

FAQ

How does Google end up indexing a Dropbox or Drive share link if the URL is so long and random?

The URL becomes findable the moment it appears anywhere a search engine crawler can read it. The pattern that produces almost every accidental indexing case is: someone pastes the share link into a forum post, a Slack channel that has a public archive, a GitHub README, a Jira ticket on a public instance, a blog post draft that gets published later, a public Google Doc, or a public Trello board. The crawler hits that page, follows the link, requests the cloud-storage URL, gets back the file (because the share setting is 'anyone with the link can view'), and the file is now in the search index. The length of the URL stops humans from guessing it. It does not stop a crawler that has just been handed it.

Wasn't there a big Box.com incident around this?

Yes - in 2019 the security firm Adversis demonstrated that thousands of Box Enterprise accounts had set their default share-link permission to 'people with the link', that the resulting URLs followed predictable patterns, and that by combining guessable patterns with subdomain enumeration they could find tens of thousands of files belonging to Fortune 500 companies, including passport scans, financial statements, intellectual property, and customer lists from Apple, Edelman, Schneider Electric, Discovery Channel, Herbalife, the City of Schaumburg Illinois, and others. The headline lesson was about the predictable URLs, but the deeper lesson was that 'anyone with the link' is not a niche risk - it is the default-on, organisation-wide footgun that turns one badly-set sharing default into a multi-thousand-file exposure.

What about the Microsoft Power Apps incident?

In May 2021 UpGuard's research team disclosed that Microsoft Power Apps portals, when configured to expose OData API endpoints, defaulted to making data publicly accessible unless the developer explicitly turned on access controls. The result was 38 million records exposed across 47 organisations including American Airlines, Ford, JB Hunt, the New York City Municipal Transportation Authority, Maryland's contact-tracing system, and Microsoft itself - data including Covid-19 vaccination records, social security numbers, employee IDs, and home addresses. The 'share link' here was the API endpoint itself, but the underlying failure mode is identical: a default-on sharing setting, no auth challenge, and the assumption that obscure equals private.

Does an expiring link or a password-protected link actually fix this?

It helps significantly, but it does not fix every failure mode. An expiring link reduces the window during which a leaked URL is useful - a link that expires in 7 days is in Google's index for at most 7 days plus whatever cache lifetime applies, and the underlying file becomes inaccessible at expiry even if the URL is captured. A password-protected link adds an auth challenge that a crawler cannot pass, so the file does not get indexed even if the URL does. The remaining failure modes are: anyone who has been given the link and the password can re-share both, the password tends to be sent in the same channel as the link (so a leak of one is usually a leak of both), screenshot-of-the-link still works as an exposure vector, and several cloud-storage products implement 'password-protected' as a one-time check rather than a per-request check, which means a session cookie set on first access keeps working after the password is changed.

What about the Referer header - what does that leak?

When you click a link on a page, your browser sends the URL of that page (the Referer) to the destination. Cloud-storage share URLs are typically opened by clicking, so the storage provider sees where the link came from. The privacy-relevant version is the reverse: when you open a share link in a browser and that page itself contains third-party scripts (analytics, fonts, ads), those scripts receive the URL of the page they are loaded on - which is your share URL, including the share token - via the Referer header. Cloud-storage providers have mostly tightened this in recent years (Dropbox and Google Drive viewer pages now send Referer-Policy: no-referrer on outbound requests), but the moment you forward the link to a tool that lets you preview or annotate it - some PDF viewers, some Markdown rendering tools, some 'open in a new tab' chat-app behaviours - the URL can leak to whatever third parties those tools load.

If I screenshot a share link and post the screenshot, is the link itself searchable?

Increasingly, yes. Google's image search runs OCR on every image it indexes, and so do Bing's and a number of vertical-search tools, which means a URL visible in a screenshot becomes searchable as text within hours of being posted on a public page. The implication for screenshots that include the browser address bar: redact the address bar before posting (with proper redaction, not a black rectangle - see our piece on PDF redaction for why), or crop the address bar out entirely. The same applies to screenshots that include any sharing UI - the share token in a 'copy link' tooltip, the URL in an email subject line that captured a notification, the OneDrive 'sharing options' modal that shows the URL inline.

Are signed S3 URLs (or the equivalent on GCS, Azure Blob) any safer than consumer-grade share links?

They are safer along one axis - they expire by default, often in minutes or hours rather than indefinitely, and the signature ties the URL to specific HTTP methods - and exactly as exposed along the other axes. A signed S3 URL is still 'anyone who has the URL gets the file' for the duration the signature is valid, it still ends up in browser histories and proxy logs and analytics pixels if it is opened in a normal browser, and it can still be indexed by a crawler that finds it before it expires. The defensible pattern for sensitive enterprise use is signed URLs with short expiry plus IP allowlisting plus access logging on the bucket, not signed URLs on their own.

What about Google Docs 'anyone with the link can view' - is that the same problem?

Yes, in the same way. The mechanism that exposed dozens of internal Bing engineering documents in 2020, that exposed many corporate Google Docs throughout 2014-2016 before Google added the noindex defaults, and that has produced periodic flare-ups since is identical: the share setting is 'anyone with the link', the link gets pasted somewhere public, Google's own crawler hits it, the document gets indexed by Google's own search engine. Google added a default noindex to documents in the consumer surface around 2017, but Workspace documents shared with 'anyone in the link' from external accounts have continued to surface in indexes, and the underlying property - that any cloud document set to 'anyone with the link' is one paste away from public - has not changed.

What is the actually private way to share a file with someone specific?

Use named-recipient sharing rather than link sharing. On Google Drive, Dropbox, OneDrive, and Box, the same UI that produces a share link also offers a 'share with specific people' option that requires the recipient to be logged in to a specific account (their Google account, their Dropbox account, etc) and that does not generate a URL anyone else can use. The trade-off is friction - the recipient needs an account on the same platform, and external-to-your-organisation recipients sometimes need to accept an invite first - but the privacy property is qualitatively better: the access is tied to an identity, the access can be revoked per identity, the access log shows which identity opened the file. For the cases where named sharing is not practical (a stranger you do not have an account for, a one-off transfer), the second-best option is a passworded link with an expiry of hours rather than days, sent through a different channel from the password.