The default way to share a cloud file is to click share, choose "anyone with the link," and paste it into a message. It works instantly, which is why it's the default behaviour for most people.
It also creates a permanent public URL to your file that will still work in five years, that anyone can forward, and that you will never think about again. Multiply that by every file you've shared and you have the most common form of accidental data exposure in personal and small business computing.
None of this requires paranoia to fix. It requires knowing which settings exist.
Two link types, and when each is right
Restricted / specific people. Only named accounts can open it. The recipient signs in, and access is tied to their identity rather than to possession of a URL.
Anyone with the link. Anyone holding the URL can open it. No sign-in, no identity, no record of who accessed it.
Use restricted by default. Use anyone-with-the-link only when:
- The recipient genuinely can't or won't sign in
- The content is genuinely not sensitive
- The link is temporary and you'll turn it off
The problem with anyone-with-the-link isn't that URLs get guessed — they're long and effectively unguessable. It's that they get forwarded, pasted into group chats, quoted in emails that get forwarded again, and occasionally posted somewhere public. The link doesn't care who's holding it.
Permission levels
Within either link type, choose the least capability that lets the person do the job:
Viewer — can open and read. Usually can also download, which is worth understanding: view access is not a way to prevent copies.
Commenter — can add comments but not change content. Ideal for feedback rounds.
Editor — can change and usually delete content, and on many services can also reshare it to other people.
That last point is the one to watch. Editor permission often includes the right to grant access to others, which means your carefully limited share can quietly expand. Most services have a setting to disable resharing by editors; turn it on for anything sensitive.
Some services also offer view-only restrictions that disable download, print, and copy. These raise the effort required to make a copy; they don't prevent it — screenshots exist. Treat them as a signal of intent, not a control.
Expiry, passwords, and the features worth using
Availability varies by service and plan, but where these exist they're worth the extra ten seconds:
Expiry dates. Access ends automatically on a set date. This is the single most valuable sharing feature available, because it solves the actual problem — not that you shared something, but that you never un-shared it. Set an expiry on every external share. Thirty days covers most purposes.
Passwords. A separate password required to open the link, sent through a different channel than the link itself. Sending both in the same email defeats the purpose entirely.
Download prevention. Discussed above — a speed bump, not a wall.
Access logs. Business plans often show who opened a file and when. Useful for confirming a client actually received something, and for noticing access you didn't expect.
Watermarking. Some services stamp the viewer's identity across previewed documents. Genuinely effective as a deterrent against forwarding.
If your service supports expiry and you use it consistently, you've eliminated most of the long-term risk in sharing without changing anything else about how you work.
Share folders, not individual files — carefully
For ongoing collaboration, sharing a folder is better than sharing thirty files: permission is managed in one place, and new files inherit it automatically.
That inheritance is also the risk. Anything you or anyone else later drops into that folder becomes visible to everyone with access. The failure mode is predictable: a shared project folder that someone treats as a general working folder, and a document lands in it that shouldn't have.
Two safeguards:
Create an explicit shared subfolder rather than sharing a folder that also contains private material. _SHARED-with-client sitting inside your project folder makes the boundary visible.
Never share a parent when you mean a child. Sharing the folder above the one you meant is one click easier and it's the most common oversharing mistake there is.
Audit what you've already shared
Every service has a way to see what you've shared, though it's usually not prominent. Look for "shared by me," "manage access," a shared filter in your file list, or an admin sharing report on business plans.
Work through the list and ask three questions of each item:
- Does this person still need access? Finished projects, former contractors, ex-colleagues, one-off recipients.
- Is this a public link that should be restricted? Convert anything sensitive.
- Is this something I'd be comfortable being public? Because that's what an anyone-with-the-link share effectively is.
Do this once, thoroughly. It takes an hour the first time and reliably finds something uncomfortable — a folder shared with a contractor from three years ago, a public link to a document containing a client list, a spreadsheet with personal details in it.
Then do it quarterly, which takes ten minutes.
What should never go in a shared link
Regardless of settings:
- Passwords, API keys, or credentials of any kind
- Identity documents — passports, licences, national identifiers
- Financial account numbers and banking details
- Health information
- Other people's personal data beyond what the recipient needs
- Anything you're contractually obliged to protect
For these, use a proper channel: a password manager's sharing feature for credentials, an encrypted transfer for documents, or a client portal. If you must send a sensitive document via cloud share, use a restricted link, add a password sent separately, set an expiry, and revoke it once received.
Turning off sharing properly
Revoking access is not always as complete as it appears:
Removing a link doesn't recall downloaded copies. Anyone who already downloaded the file has it forever. Revocation stops future access, not past copies.
Cached previews may persist briefly.
Copies made by editors are theirs. If someone with edit access made a copy into their own drive, that copy is a separate file you don't control.
The practical implication: sharing is a one-way decision for anything genuinely sensitive. Revocation limits ongoing exposure and doesn't undo what's already happened. Decide before you share, not after.
Sharing with people outside your platform
The friction point in most sharing is recipients without an account on your service.
Options, in order of preference:
Send a restricted link to their email address. Most services can grant access to a specific email without requiring a full account, sending a one-time verification code instead. This gets you identity-tied access without forcing a signup.
Export to PDF and attach it. For a one-off document that doesn't need collaboration, an attachment is often simpler for everyone and leaves no live link behind.
Use a link with a password and an expiry. Where the recipient genuinely can't authenticate.
Don't ask an external recipient to create an account for a single file. It's a poor experience and they frequently won't, which means the thing you needed to deliver doesn't get delivered.
The five-second habit
When you share something, ask two questions:
Does this need to be a public link, or will a named person work?
When should this stop working?
Answering those two, every time, prevents nearly every sharing problem that this article otherwise exists to clean up.
Sharing features, expiry availability, and permission models vary by service and plan, and change over time. Check your provider's current options.
Next in this series: Cloud Storage Costs Compared: What You Get Per Dollar