An upload field is a small door with an unusually large risk behind it. It may admit a useful photograph, a 900 megabyte video, a disguised archive or a document containing confidential personal data. Checking the extension and placing the file in a public folder does not constitute a professional upload
A file makes many claims
The name invoice.pdf proves neither format nor content. The media type reported by the browser can also be manipulated. Dependable validation combines an allowlist of extensions, detected file signature, actual media type and size limit. Safe reencoding of images can remove additional embedded content. Archives need separate rules because they may contain extremely large numbers of files or expand far beyond their compressed size
The allowlist follows the use case. JPEG, PNG and PDF may be enough for a damage report. A project brief may also need spreadsheets or CAD formats. “All files” is not user friendly openness. It is a product decision left unanswered
The safe route through the system
- The server creates an upload session with a random identifier and expected limits
- The file receives an internal name unrelated to the user supplied name or original path
- It enters isolated storage that cannot execute or serve the file publicly
- Inspection, malware scanning and any content processing run in an isolated queue
- Only after approval is the file attached to the business case
- Downloads pass an authorisation check or use a short lived signed address
This route stops a new file becoming immediately accessible at a guessable URL. It also exposes the intermediate state: “uploaded and being checked” is different from “released for processing”
Large files need a protocol
On a mobile connection, one long transfer can fail in its final minute. Chunked and resumable uploads transfer blocks and confirm progress. A checksum then verifies that the complete file arrived. Retries must not attach multiple copies to the case
Progress indicators should reflect the real transfer. An animation with no measured progress creates false confidence. If the tab closes, users need to know whether the upload can resume or must start again
Photographs are data packages
Smartphone photographs can contain location, device and capture time in their metadata. Location can be useful in an incident report, in which case it should be requested and confirmed deliberately. In other situations, metadata should be removed before internal distribution
Previews should not load unexamined originals directly into another user’s browser. A safe preview generated on the server reduces risk and accelerates review
Privacy does not end with a notice
The form explains which documents are needed and which information should not be uploaded. A CV, identity document and photograph of machinery have very different protection needs. Retention should follow the case. Abandoned uploads and unsent drafts need automatic deletion too
Internal operators see only files for their cases. Particularly sensitive documents may require an additional role or fresh authentication. Every download of a critical file should be traceable
Error text is part of the security architecture
“Invalid file” makes users guess. “This file is larger than 25 MB” or “This form accepts PDF, JPG and PNG” gives a correctable reason. Scanner details remain internal, while a reference number connects the user’s report with the system log
Business value starts after the scan
A safe file without context is still hard to process. The form should capture what the file shows, which site or order it concerns and what action is expected. The article on enquiries with photos, location and urgency presents a useful model for technical services. If documents have versions, deadlines and approvals, the form is becoming a supplier portal
A good upload is uneventful for the user: clear limits, genuine progress and unambiguous confirmation. The complexity stays where it belongs, inside a controlled processing chain