Protect sensitive files through a delivery mechanism that checks authorisation before serving the file. A hidden link, an unlisted page or a password-protected post does not automatically secure a file stored at a publicly reachable uploads URL.
IN THIS ARTICLE
01 Define who may download
Identify the intended users, whether access expires and whether each person needs individual revocation. Decide whether the file is confidential, customer-specific or merely unpublished marketing material. Those requirements determine the suitable storage and delivery design.
Do not upload a confidential document to a normal public Media Library location as an experiment. Removing the link later does not recall a direct URL already exposed or cached.
02 Implement a supported access boundary
- Choose a maintained document, membership or application solution that explicitly protects the underlying file delivery.
- Confirm where files are stored and how requests are authorised, including direct URL requests.
- Configure the required user roles or entitlements and test with separate allowed and denied accounts.
- Check cache and CDN rules so a permitted user's response is not reused for another visitor.
- Document the revocation and deletion process before placing production documents in the system.
How do I check whether the direct file URL is still public?
Copy a file's direct URL and open it while signed out and from an account without permission. Confirm that the protection applies there as well as on the page containing the link. Test expired access and a revoked account where those controls are required.
Signed links can be useful in a supported storage system, but their expiry and sharing behaviour must match the intended protection. Treat a valid signed URL as sensitive while it remains usable.
03 Respond to an accidental public upload
Restrict or remove access promptly, record the exposed URL and review caches and external distribution. Ask for help if the file contains sensitive customer or account information. Do not assume a robots instruction or a difficult filename makes the data private.
Keep backups and retention requirements in the recovery plan. Replacing an entire database is not normally the right way to remove one exposed file, and a later restore should not silently make it public again.