Separate upload names from storage identity
Treat the original filename as display data. Define server-owned storage keys, collision behavior, Unicode handling, and safe download-name serialization.
An uploaded filename serves several possible roles: a display label, a storage path, and a suggested download name. Do not make one untrusted string responsible for all three. Use an application-generated identity for storage and retain a separately validated display name where the product needs it.
OWASP recommends application-generated filenames. MDN documents Content-Disposition for download presentation. Neither a display label nor a download suggestion should decide which stored object a caller can access.
Specify the naming contract
Write down maximum display length, accepted character handling, and the rule for duplicate visible names. Choose normalization deliberately and preserve enough information to explain a changed name to the uploader. Avoid silent replacement that makes two different documents indistinguishable.
| Name condition | Storage behavior | Display or download behavior |
|---|---|---|
| Two identical names | Distinct server-owned object identities | Show version or upload context |
| Path separators | Never determine a filesystem path | Reject or normalize under a documented rule |
| Control characters | Never enter headers or logs literally | Reject the name |
| Long Unicode name | Storage identity remains bounded | Apply a documented length policy |
Record the original filename only where needed and with appropriate access controls. It can contain personal or confidential information.
Test each place the name appears
Use synthetic names containing quotes, separators, mixed case, and composed or decomposed Unicode. Check the upload response, document list, search results, audit view, and download prompt. Verify that the displayed value is text, not markup.
Construct response headers with a supported serializer rather than string concatenation. Confirm that a download name cannot add another header or change the selected object. Also test a missing filename so the fallback remains predictable.
Keep renaming out of authorization
A user may rename a visible document without changing its tenant or ownership. Check that the rename operation does not reconstruct a storage path from the new label. Likewise, deleting a file should resolve the trusted object identity rather than matching a user-supplied filename.
Save the naming policy and fixture results with the upload component. After a storage migration, rerun collision and path tests against the new backend. The completed review should demonstrate that hostile or ambiguous labels cannot change storage selection, while legitimate users can still recognize and download their documents.
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
- MDN: Content-Disposition headerAccessed