The single most common “how did this happen” story I encounter goes like this: a customer support engineer needs to share a runbook with a vendor for 20 minutes, sets the file to Anyone with the link can view, pastes the URL into an email, and forgets. Three years later that file shows up in a Google search for site:docs.google.com “internal use only”.
It is not a clever attack. There is no exploit chain. The link was simply published, indexed, and never expired. This post is about why that pattern is the biggest practical Drive risk most organizations face, and what to do about it without breaking workflows.
Why “Anyone with the link” gets reached for
It is the path of least friction. Setting a Drive file to Anyone with the linktakes one click. Sharing with a specific email requires the recipient to be authenticated to a Google account on that email, which is not always the case for vendors, freelancers, or government partners. Faced with “send the file in 30 seconds” vs “coordinate a Google identity for the vendor”, most people pick the first option every time.
That is not a user problem. It is a default problem. The fix is to make the secure path the easy path — which is what the rest of this post is about.
How a private link becomes a public file
A Drive link is just a URL. Anything that touches a URL eventually leaks it. The four most common channels I see in incident postmortems:
1. Email forwarding
The original recipient forwards the message to a colleague at a different company, or to their personal Gmail. The link now lives in two inboxes you do not control. If either of those inboxes is later compromised in a credential stuffing attack — a technique that, per the 2024 Verizon DBIR, was a factor in roughly a third of basic web application breaches — the file is accessible to whoever holds the credentials.
2. Public pages and bookmarking
Drive links pasted into community forums, status pages, GitHub issues, public Notion docs, or vendor knowledge bases are crawled by search engines. Once crawled, they are searchable. There is a long history of journalists, researchers, and security folks finding sensitive documents this way using nothing but Google dorks like site:drive.google.com filetype:pdf confidential.
3. Browser extensions and clipboard tools
Many productivity extensions read URLs from the page or the clipboard. Extensions that mishandle telemetry, or that get sold to a new owner who changes the data practices, can end up shipping your URLs to third parties. This is not theoretical — there have been multiple CISA advisories about extensions exfiltrating browsing data.
4. Screen-sharing and screenshots
Watch any conference talk recording where the presenter has a Drive tab open. The URL bar is right there. URLs are also captured in support tickets, Slack screenshots, and bug reports. Anyone with the link is exactly that — anyone.
Why it is worse than it looks
Three properties make “Anyone with the link” uniquely durable as a risk:
- Permissions do not expire by default. A link from 2020 still works in 2026 unless someone explicitly revoked it. Workspace supports per-grant access expiration, but it has to be set at the time of sharing and most people do not set it.
- The audit log only tells you about views from authenticated users. Anonymous viewers of a public link do not show up by user identity. You can see that the file was opened, but not by whom.
- You cannot search inside someone else’s clipboard. Once a link has propagated outside Drive, recovery is approximate at best. The only reliable mitigation is revocation.
What to do about it
1. Inventory before you change defaults
If you flip your domain default from “Anyone with the link” to “Restricted” without warning, you will break workflows and create political backlash. Inventory first. The Drive log events report in the Admin console exposes visibility per file. You want a CSV of every file currently set to people_with_link or public, along with owning OU and last activity date. This is the single most useful artifact you can produce in the first week of an audit. The general approach is in our Google Drive security audit checklist.
2. Change the default for new files
In Apps > Google Workspace > Drive and Docs > Sharing settings, set Default for link sharing to Off for at least the OUs that handle sensitive data (Finance, Legal, HR, Engineering). This is a forward-only change — it does not retroactively rewrite existing files — so it is safe to ship without a long change-management cycle.
3. Warn the user at share time
Workspace can show a warning when someone tries to share with an external recipient. Turn this on under Drive and Docs > Sharing settings > Warning when sharing outside [your domain]. The cost is one extra click; the benefit is a moment of reflection.
4. Expire or rewrite existing public links
For files that legitimately need external access, replace anonymous links with explicit grants to specific email addresses, plus an access expiration. For files that should never have been public, revoke. Doing this by hand for a backlog of five thousand files is impractical, which is why we built bulk remediation into ClearVew: select files by visibility and risk score, then revoke or rewrite in a single action.
5. Monitor for new public links
Even with defaults locked down, individual users can still override. Add an alert rule that fires whenever a file is set to public visibility outside of an allowlisted OU. This is also where continuous risk scoring earns its keep — an alert tells you something happened, but a risk score tells you whether it matters.
What not to do
A few patterns I have seen fail:
- Mass revocation without notice. Revoking thousands of links overnight will break sales decks mid-pitch and customer onboarding flows mid-call. Communicate, stage, and provide a self-service way to request re-grants.
- Banning external sharing entirely. External collaboration is why Drive exists. The right answer is policy, not prohibition. The external sharing policy guide covers what that should look like.
- Treating one-time cleanup as the goal. Drive permissions decay continuously. Without continuous monitoring, the backlog grows back inside a year.
The mindset shift
The most important shift is treating link sharing as a capability that requires active management — like a firewall rule, or an IAM policy. It is not a setting you configure once at onboarding and ignore. The file you set to “Anyone with the link” in 2024 is the breach you are explaining in 2027.
For a deeper look at the policy controls Workspace gives you to do this without making people miserable, read Google Workspace External Sharing: A Practical Policy Guide.
