Start with the job the upload needs to do
Before adding an upload field, write down why the site needs a file and who should be allowed to send one. A contact form that needs a reference image has different requirements from a client portal that accepts documents. If a text field or a link would meet the need, skipping the upload removes an entire area of risk and maintenance.
Choose a short list of permitted file types based on that purpose. For example, a form requesting photographs may only need common image formats. Avoid accepting every type “just in case,” particularly files that a browser can run or display as active content, such as HTML and SVG. Set a reasonable maximum file size and, where relevant, a limit on the number of files per submission. These limits help control storage use and make unexpected submissions easier to spot.
Check every upload on the server
A browser can help visitors choose the right file, but its checks are not a security boundary. Apply your rules again on the server before accepting or processing an upload. Check the actual file size, reject empty files, and use the server’s file inspection tools to confirm that the contents match a permitted format. A filename extension or a file type reported by the visitor’s browser is not sufficient evidence on its own.
Give each accepted file a new, unpredictable storage name rather than using the visitor’s filename as a path. If you need to display the original name to staff, keep it as separate data and treat it as untrusted text. Do not let an uploaded name determine a directory, overwrite an existing file, or become part of a command. Image resizing, document previews, and other processing add complexity; keep the software that performs those tasks updated and avoid generating previews you do not need.
Keep stored files separate from the website
The safest useful storage arrangement depends on your hosting setup, but uploaded files should not become executable website code. Where possible, store them outside the public web directory and provide access through an application that checks permissions. If files must be stored in a web-accessible location, configure that location so uploaded content cannot run as scripts, and test the configuration after deployment.
Decide who may upload and who may retrieve each file. A public enquiry form may need to accept submissions from anyone, while the resulting files should be visible only to authorized staff. A private client upload needs checks on both the upload request and every later download request. Do not assume a hard-to-guess URL is a substitute for access control. When serving downloads, use appropriate response headers so the browser is less likely to treat an uploaded file as a page on your site.
Limit abuse and protect the people using the form
Public upload forms can attract spam or repeated large submissions. Set request and storage limits, and consider rate limiting that fits your expected traffic. For signed-in users, require a valid session and protect upload actions against cross-site request forgery. If you use malware scanning, treat it as an additional check, not a replacement for file restrictions, safe storage, and access controls. Plan what happens when a scan cannot complete rather than silently treating the file as safe.
Tell visitors which file types and sizes you accept before they submit. If a file is rejected, give a clear error that identifies the problem without exposing server paths or internal configuration. Keep any personal information collected with the file to what you need for the task. Decide how long uploads should be retained, who is responsible for deleting them, and whether they belong in backups. A folder of forgotten attachments is both a storage burden and a privacy concern.
Make uploads part of routine maintenance
Test the full path from submission to deletion before launch. Try an allowed file, an oversized file, a renamed unsupported file, and a filename containing unusual characters. Check that unauthorized visitors cannot retrieve private uploads, that rejected files are not left behind, and that error messages work for people using a keyboard or screen reader. Repeat the important checks when hosting settings, form software, or file-processing tools change.
Keep a simple record of rejected uploads, processing failures, and storage growth, without logging sensitive file contents. Review that record and the upload folder on a schedule that suits the site. File uploads are not a set-and-forget form feature: a narrow purpose, server-side checks, careful storage, and a deletion plan make them easier to support over time.
