Separate uploaded bytes from application content
Map upload storage, processing, and serving identities. Verify that uploaded files cannot become executable site content or bypass the download policy.
Moving uploads into a directory named private does not establish a serving boundary. Determine which process can read that directory, which routes expose its contents, and whether a web server can interpret any stored format as executable application content.
OWASP recommends separating uploads from the web root. For object storage, apply the same review question to bucket access and serving endpoints. The storage location and the download policy must agree.
Draw the three identities
Separate the uploader-facing application, the processing worker, and the component that serves accepted files. Record the minimum storage operations each identity requires. A thumbnail worker usually does not need permission to replace application code or list every customer's documents.
| Identity | Necessary access | Boundary to verify |
|---|---|---|
| Upload receiver | Create a new pending object | Cannot overwrite application assets |
| Processing worker | Read assigned input and write assigned output | Cannot traverse unrelated objects |
| Download service | Read authorized accepted objects | Cannot expose quarantine by arbitrary key |
| Cleanup task | Remove expired temporary objects | Cannot delete outside its recorded scope |
Use server-generated object identities. Keep any original filename as metadata rather than a path instruction.
Inspect every serving shortcut
Check static-file mappings, public bucket settings, CDN origins, and preview routes. A download handler with strong authorization is ineffective if the same object remains public through another hostname. Include historical URLs that the application may have issued before a storage change.
Use a harmless text fixture to test direct access. Do not upload executable samples to a production web root. In an approved staging environment, verify that pending and unauthorized objects cannot be fetched through guessed storage paths or alternate serving routes.
Define the accepted-file response
Choose a controlled content type and download disposition for the supported use case. Treat active formats and inline previews as separate product decisions. A file accepted for storage does not automatically become trusted page content.
Keep the serving configuration, storage policy, and application authorization tests in one change record. Recheck them when adding a CDN or moving to direct object-store links. Confirm that an allowed user can still download an accepted fixture after the change. The completed review should show that uploaded bytes remain data, that processing identities have bounded access, and that every public retrieval path uses the intended publication and permission rules.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.
Sources
- OWASP File Upload Cheat SheetAccessed