Secure File Uploads in Business Applications: Validation, Storage and Access Controls
How to secure file uploads in business applications: allowlists, content checks, malware scanning, private storage, presigned URLs, safe serving, retention.
How do you secure file uploads?
Allow only the file types you need, validate size, extension and actual content, rename files, store them privately outside the web root (usually object storage), upload directly with short-lived presigned URLs, quarantine and scan before use, re-encode images where practical, and serve files only after authorisation from a separate domain with safe headers. Apply retention and deletion rules, because uploads often contain personal data. The OWASP File Upload Cheat Sheet is the standard reference.
This guide is for engineering teams building portals, onboarding, claims, HR and document features.
Key takeaways
- Allowlist types; verify content, not just extensions.
- Store privately with generated names.
- Quarantine and scan before files are used.
- Authorise every download.
- Serve with safe headers, ideally from a separate domain.
- Set retention and deletion.
Threats and controls
| Threat | Control |
|---|---|
| Executable or script upload | Extension allowlist, content signature checks, never store in an executable path |
| Stored XSS via HTML or SVG | Block or sanitise SVG and HTML; serve as attachment from a separate domain with nosniff |
| Malware shared with others | Quarantine and scan before release |
| Denial of service | Size limits, archive bomb checks, rate limits |
| Path traversal and overwrites | Generated file names and keys; ignore user-supplied paths |
| Unauthorised access | Private storage, per-object authorisation, short-lived signed URLs |
| Metadata leaks | Strip EXIF and document metadata where appropriate |
Recommended upload flow
- Client requests an upload; the server checks permissions and issues a short-lived presigned URL for a quarantine location with size and type constraints.
- Client uploads directly to storage.
- A storage event triggers validation (type, size, structure) and malware scanning.
- Clean files move to the permanent private location; failures are deleted and the user told.
- The application records metadata: owner, record, type, size, checksum, scan result.
- Downloads go through an authorisation check, then a short-lived signed URL or proxied stream.
Hypothetical example: an insurance claims portal
This example is hypothetical. A claims portal let customers upload photos and PDFs to a public folder with original file names. The team moved uploads to private storage via presigned URLs, added type allowlists and content checks, scanned files in quarantine, stripped image metadata, and served files to handlers only through authorised, expiring links from a separate domain. Retention rules now delete files when claims close plus the agreed period.
Common mistakes
- Trusting the extension or Content-Type header.
- Public buckets or predictable URLs.
- Serving user files from the main application domain inline.
- No size limits or scanning.
- Keeping uploads forever.
Sources
OWASP File Upload Cheat Sheet; AWS S3: uploading objects with presigned URLs.
Accessed 10 October 2026.
Conclusion
Secure uploads come from layers: allowlists and content checks, private storage and presigned uploads, quarantine and scanning, authorised and safely served downloads, and retention. See API security best practices and threat modelling for web applications.
Adding document or photo uploads to your application?
ZSpace Labs is a remote-first technology studio that works with clients globally on secure web applications. If it would help to review your upload design, we are happy to talk it through.
Common questions.
Malicious files executed on the server or in users' browsers, malware passed to other users, oversized files or archive bombs exhausting resources, files overwriting others, and users accessing files they should not see.