Define the accepted input
State the file types, size limits, and information the workflow expects. Validate content using an appropriate server-side process rather than relying only on the filename or browser checks. OWASP: file upload guidance.
Decide who can upload and who can later retrieve the file. Store uploads with access controls appropriate to their contents, and avoid making a storage location public simply because the interface needs to display a download button.
Represent processing explicitly
A file may be received, checked, queued, processed, or rejected. Give the user an understandable status and a durable reference. If processing is asynchronous, allow the person to leave and return without losing the result.
Explain errors at the stage where they occur. A malformed file should not appear as a network upload failure, and a processing service outage should not imply that the person selected the wrong file.
Plan cleanup and correction
Define how long original files and derived results are retained, based on the application’s needs and applicable requirements. Make deletion behavior consistent with the rest of the workflow, including any records created from the file.
Provide a way to replace a rejected file without losing the history needed to understand the attempt. For partially processed files, show what was completed and what a repeat will do.
Test a interrupted upload, a valid-looking file with invalid content, and a processing failure after storage succeeds. These cases reveal whether the application has a coherent file workflow or only a successful demonstration of a browser sending bytes.
A practical example.
An application accepts supporting documents for a request. Receiving the bytes, validating the file, processing it, and making it available are separate steps with different failure modes. The interface should not announce that a document is ready simply because the transfer finished.
Define acceptable file types and sizes on the server, choose how files are stored and served, and decide which checks must finish before access is allowed. Consider a processing failure after the upload was accepted: the user needs a clear status and a supported retry or replacement action. Test permissions on both the upload endpoint and the eventual download. A private request does not remain private if its attachments are accessible through unrestricted links.
Put it into practice.
- Separate upload completion from processing and availability.
- Apply server-side validation and suitable handling for the intended file types.
- Check storage, download permissions, failure cleanup, and replacement behavior.