A file-sharing link's actual security depends entirely on how it was configured, and it's easy to accidentally create or receive one that's more exposed than intended — visible to anyone with the link, or even discoverable without it, rather than genuinely restricted to the people it was meant for.
Signs a link might be shared more broadly than intended
- No access restriction option was set, meaning anyone with the link, however they obtained it, can view or download the file.
- The link works without ever asking for any sign-in or verification, which is fine for genuinely non-sensitive content but worth double-checking for anything that shouldn't be broadly accessible.
- The link appears to still work long after you'd expect it to have expired, suggesting no expiration was actually set despite an assumption that it would be temporary.
Checking your own sharing settings before sending a link
- Before sharing, check the specific access level the link grants — anyone with the link, only specific people, or restricted to your organisation, depending on what the sharing service offers.
- Set an expiration date if the service supports it and the content doesn't need to remain accessible indefinitely.
- Confirm whether the link allows editing or only viewing, and restrict to view-only unless editing is genuinely needed.
Why "anyone with the link" settings are riskier than they sound
A link set to allow access to "anyone with the link" is more exposed than it might feel, since links get forwarded, appear in browser history, get logged by various services along their path, and can occasionally be discovered through other means. Treat this setting as meaningfully more open than sharing with specific named people.
What to do if you've received a link that seems too open
If you receive a file-sharing link that seems unexpectedly unrestricted for what it contains, it's reasonable to flag this to whoever sent it, particularly if the content is genuinely sensitive. This isn't an overreaction — a quick check and a possible correction is a small cost compared to unintended broader exposure.
Revisiting old shared links periodically
Links created for a past project or a one-off share have a habit of quietly staying active long after their original purpose ended. Periodically reviewing your own account's active shared links, and revoking or expiring ones that are no longer needed, is a reasonable habit for anyone who shares files regularly.
Choosing the right access level for the actual sensitivity involved
Not every shared file needs the most restrictive possible setting — genuinely non-sensitive content is fine shared more openly. The goal is matching the access level to the content's actual sensitivity, rather than defaulting to either extreme without thinking through the specific situation.
Understanding how a link can be discovered without being directly shared
Beyond someone forwarding a link they received, an overly permissive link can sometimes be discovered through less obvious means — appearing in a service's own search indexing if the sharing platform allows it, or through a browser history sync across devices. This is part of why treating a broadly-accessible link as more exposed than a restricted one is a reasonable, cautious default.
Checking sharing defaults on the specific service you use
Different file-sharing and cloud storage services have different default sharing behaviours, and it's worth understanding your specific service's actual default before assuming it matches your expectations. A service that defaults to broad access, requiring you to deliberately restrict it, behaves quite differently from one that defaults to restricted access requiring deliberate opening up.
What to do before sharing something genuinely sensitive via a link
For anything genuinely sensitive, pause before generating a share link and deliberately choose the most restrictive setting the service offers that still lets the intended recipient access the file, rather than defaulting to whatever the service's standard option happens to be, which isn't always the most restrictive one available.
Recognising the tradeoff between convenience and restriction
A more restricted sharing setting is sometimes slightly less convenient — requiring the recipient to sign in, for instance, rather than clicking straight through. For anything sensitive, this small extra friction is a reasonable and worthwhile tradeoff, even though it wouldn't be necessary or proportionate for something low-stakes.
Checking access logs if your sharing service offers them
Some file-sharing services let you see who has actually accessed a shared link and when. If this feature is available and the content is sensitive, periodically reviewing that access log is a reasonable additional check beyond simply trusting the initial sharing configuration was correct.
Treating a link's security as something to verify, not assume
The overall habit worth building here is treating a sharing link's actual configuration as something to actively verify each time for sensitive content, rather than assuming past experience with a service guarantees the current link is set up the way you'd expect.
Frequently asked questions
Is "anyone with the link" access inherently unsafe?
Not for non-sensitive content, but it's meaningfully more exposed than restricting to specific people, and worth reconsidering for anything sensitive.
Should shared links always have an expiration date?
For anything that doesn't need to remain accessible indefinitely, yes, setting an expiration reduces long-term exposure.
What should I do if I receive a link that seems too open for its content?
Flag it to whoever sent it; a quick correction is a small cost compared to unintended exposure continuing.
Should I review my own old shared links periodically?
Yes, links created for a past purpose often stay active longer than intended if not periodically reviewed and revoked.
Does every file need the most restrictive sharing setting?
No, match the access level to the content's actual sensitivity rather than defaulting to one extreme.
Can a link still be accessed after it seems like it should have expired?
If no expiration was actually set, yes; check that an expiration date was genuinely configured, not just assumed.
Are the file tools on this site affected by this issue?
Files processed here are provided as a direct download and automatically removed from our servers about an hour later, rather than via an open, indefinitely-accessible link.