Insecure file uploads: why your "upload your CV" form is a risk
Any form that accepts files is a door into your systems. How upload attacks work and the seven controls that close the door.
The short answer
A form that accepts files, a CV, a photo, a document for a quote, lets strangers place content on your infrastructure. That is fine when the content is treated as inert bytes and stored somewhere nothing will ever run it. It is a serious vulnerability when the web server can execute the file, serve it as a page, or when a staff member opens it without protection. Upload attacks are old, common and well understood, and the controls against them are equally well understood. The file’s name and extension prove nothing; what matters is where it goes and what can happen to it there.
How the attacks work
| Attack | How | What it achieves |
|---|---|---|
| Executable disguised as document | A script renamed to look like a PDF or image, uploaded to a folder the server executes | Full control of the server |
| Script inside an image | Valid image with embedded code, served from your domain | Cross-site scripting against your visitors or admins |
| Path tricks in the filename | A name that escapes the upload folder | Overwriting configuration or code |
| Oversized or zip-bomb files | Very large or highly compressed files | Denial of service, disk exhaustion |
| Malware for humans | A document that attacks whoever opens it | Compromise of a staff laptop, then the network |
| Content the law forbids | Illegal material placed on your storage | Legal exposure for you |
The seven controls
- Allow-list by actual content. Check the file’s bytes against the small list of types you accept; reject everything else. Never trust the name or the declared type.
- Limit size, per file and per request, before reading the whole thing.
- Rename on storage to a generated identifier; keep the original name only as metadata, escaped.
- Store outside the web root, ideally in dedicated object storage the web server cannot execute from.
- Never execute, never include. Nothing in the upload location is ever run or included by application code.
- Scan files that humans will open, on upload, and quarantine on detection.
- Serve safely, if at all: from a separate domain, with headers that force download or forbid type guessing, and only to people entitled to see the file.
The design that stays safe
On a modern static site, uploads go to a function that validates content and size, writes the bytes to object storage under a generated name, records metadata in a database, and returns a confirmation. Files are served, when needed, through a signed link from a separate domain with strict headers, or never served publicly at all. Staff open documents in a viewer that renders them safely rather than on their own machines. Nothing in the path executes what a stranger uploaded.
What this means for you
Every upload form is a door. Keep it, if the business needs it, but make sure what comes through it is checked by content, limited in size, renamed, stored where nothing executes, scanned if humans will open it, and served safely or not at all. Those seven controls turn one of the oldest attack paths on the web into a non-event, and they cost a few hours to implement once.
Frequently asked questions
We only accept PDFs. Is that safe?
Safer, if the check is on the file's actual content and not its name, the size is limited, the file is stored outside anything the web server executes, and staff open it in a sandboxed viewer. PDFs themselves can carry malicious content aimed at the person opening them, so the storage and viewing side matters as much as the upload.
Is a static site immune to upload attacks?
The static pages are, because nothing executes on the web server. The function that receives the upload and the storage it writes to are the surface. Handle the file in the function as bytes only, write it to object storage with a generated name, and serve it, if at all, from a separate domain with strict headers. That design keeps the surface small.
Do we need virus scanning?
For files that staff or customers will open, yes: a scan on upload catches known malware before a person does. It is one control among seven; on its own it misses novel payloads, and it does nothing about a file that is dangerous because of where it was stored rather than what it contains.
Sources
- OWASP Cheat Sheet Series: File Upload (accessed 2026-09-11)