📁 File Upload, Download, and Browser Rendering Risks
Intro: Upload and download features are deceptively expensive from a security perspective because they combine parsing, storage, rendering, authorization, and content delivery. Teams usually think about malware scanning first; attackers often win through rendering, sharing, or retrieval mistakes instead.
What this page includes
- a threat model for upload and download features
- browser rendering and content-type pitfalls
- storage and retrieval controls
- review questions for engineering and product teams
Think in four stages
- accept the file;
- store it safely;
- process or scan it;
- serve it back without turning the browser into an execution surface.
Upload controls
At minimum, enforce:
- file size limits;
- allowed-type validation based on business need, not only extension;
- storage outside executable web roots;
- server-side generated object names;
- authorization on upload intent, not just on API path access;
- quotas per user, tenant, and workflow.
Download and rendering controls
A safer default is to treat untrusted content as downloaded content, not as immediately rendered active content.
Review the following questions:
- Will the browser render the file inline?
- Can the file execute script, load remote content, or trigger client-side parsing?
- Does the response set a trustworthy content type?
- Can the file be downloaded by a different tenant or a stale shared URL?
- Are signed URLs scoped tightly enough and short-lived enough?
Dangerous patterns
- allowing SVG, HTML, or script-capable content to render inline on authenticated origins;
- trusting only client-supplied MIME type or extension;
- permanent or long-lived public links for sensitive exports;
- using original attacker-controlled filenames in paths or headers without normalization;
- serving uploads from the same domain and origin policy as high-value application pages.
Safer architecture patterns
| Pattern | Why it is safer |
|---|---|
| dedicated download domain | reduces authenticated-origin rendering risk |
| forced attachment download for untrusted content | avoids inline execution and active rendering |
| signed, short-lived URLs | narrows unauthorized retrieval window |
| async scanning and quarantine | keeps processing logic separate from serving logic |
| authorization on retrieval | prevents “upload once, download by anyone” failures |
Review questions for exports
Exports are often more dangerous than uploads because they involve bulk sensitive data.
Ask:
- What role can start an export?
- Is export scope server-side authoritative?
- Does the product re-check tenant and object ownership at export generation time?
- How is the export stored, encrypted, shared, and expired?
- Is the user notified when a high-risk export completes?
Practical checklist
- allowed types mapped to a business reason
- active content types reviewed separately from inert content
- upload storage separated from application code paths
- retrieval requires authorization or a short-lived signed URL
- content disposition and content type explicitly reviewed
- tenant boundary tested with another tenant’s identifiers or URLs
- download telemetry available for anomaly detection
Related pages
- SSRF, File Fetch, and Parser Abuse Review Guide
- Third-Party Scripts, File Handling, and Frontend Supply Chain
- Business Logic Abuse Review Playbook
Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.