Private File Accessible by Direct URL
A file that should only be visible to its owner (or to authorised users) can be downloaded by anyone who has the direct file URL — including logged-out users and other accounts. The application checks permissions on the page that lists the file, but the storage URL itself serves the file with no access check.
HighBeginnerSecurity testingManual testingAPI testing
// UNDERSTAND
// Symptoms
- Opening a file's direct URL in an incognito window downloads the file without logging in
- A user can open another user's file by pasting the file URL
- A deleted file is still downloadable from its old URL
- Private files appear in search engines or are reachable on a predictable path
// Root Cause
- Files are served from a public storage bucket or static path with no per-request authorization
- Access control is enforced only in the UI/listing, not on the file-serving endpoint
- Signed URLs are not used, or signed URLs never expire
- Deleting a record does not delete or revoke access to the stored object
// Where It Appears
- Document, image and attachment uploads in SaaS apps
- Invoice, report and export downloads
- Avatar and profile-media storage
- Any feature backed by object storage (S3-style buckets) or a /uploads path
// REPRODUCE & TEST
// How to Reproduce
- 01As User A, upload a private file and copy its direct download URL from the network panel
- 02Log out (or switch to User B in an incognito window)
- 03Open the copied URL directly
- 04Confirm whether the file downloads — a private file should return 401/403/404, not the file
- 05Repeat after deleting the file to confirm the old URL no longer serves it
// Test Data Needed
- Two test accounts (User A and User B)
- A private test file owned by User A (use an ordinary, safe file — no real personal data)
- Browser developer tools to capture the file URL
// Manual Testing Ideas
- Open the direct file URL while logged out and as a different user
- Increment or alter an id/filename in the URL to probe for predictable paths (stay in scope)
- Delete the file, then re-open the captured URL
- Check whether the file preview respects the same permissions as download
// API Testing Ideas
- Request the file endpoint with no auth header and confirm 401/403
- Request User B's file using User A's token and confirm it is refused
- If signed URLs are used, confirm they expire and cannot be replayed after expiry
// Automation Idea
In a controlled test environment, automate a check that requests a private file URL with (a) no token, (b) a different user's token, and (c) after deletion — asserting a non-200 in every case. Run it whenever upload or storage code changes.
// Expected Result
The file-serving endpoint enforces authorization on every request; private files return 401/403/404 to anyone who is not authorised, and deleted files are no longer downloadable.
// Actual Result (Example)
GET on the direct file URL returns 200 and the file body with no authentication, so any user (or a logged-out visitor) who has the link can download a private document.
// REPORT IT
Example Bug Report
- Title
- Private uploaded file downloads via direct URL without authentication
- Severity
- High
- Environment
- Staging · build 2026.06.03 · Chrome 126
- Steps to Reproduce
- 01As User A, upload a private document and copy its URL from the network panel
- 02Open an incognito window (logged out)
- 03Paste and open the file URL
- Expected Result
- The request returns 401/403/404 — the file is private.
- Actual Result
- The request returns 200 and the document downloads with no login.
- Impact
- Any private uploaded file is readable by anyone with the link, including logged-out visitors — a confidentiality breach.