Secure File Uploads: Keep Customer Attachments from Becoming Web Shells

Follow one attachment through its whole life

A contact form that accepts a document creates more than a file-input field. The application receives untrusted bytes, may parse them, stores them and later serves them to another person. An upload can therefore affect code execution, storage availability and customer privacy. This is a practical prevention guide reviewed in November 2026; it does not describe a newly discovered vulnerability or claim that a scanner alone makes uploads safe.

Write down the business requirement first

Start with a concrete example: a support customer needs to submit a PDF receipt under a defined size. Ask whether archives, SVG files, office macros or arbitrary file types are actually necessary. A smaller supported set makes validation and user communication clearer. Explain rejected formats beside the form so people do not repeatedly rename files in an attempt to bypass the restriction.

OWASP recommends layered upload controls, including an extension allowlist, file-type validation, generated filenames, size limits and storage outside the web root where possible. Client-supplied content types are not trustworthy evidence. The authorization boundary also applies when an attachment is retrieved, not only when it is submitted.

Use private storage and a deliberate release step

Keep the original file outside executable public paths. Assign a generated identifier and preserve the display name separately as untrusted text. An authorized download controller can map that identifier to storage after checking ownership or staff permissions. A hard-to-guess URL does not replace that check. For intentionally public media, serve a reviewed derivative through a separate path with appropriate content handling.

Make quarantine a real state. Pending files should not be downloadable simply because the upload request succeeded. Define what happens when the scanning or processing service is unavailable: keep the file pending, notify the appropriate operator and show the customer an honest status. Avoid silently treating a timeout as approval.

Budget processing resources

Image conversion, archive inspection and document parsing need separate resource limits. Decide the maximum upload bytes, decoded image dimensions, processing time, concurrent jobs and total storage per account. Place workers behind a constrained queue rather than asking the web request to process everything immediately. Keep the processor’s credentials limited; it should not need deployment keys or unrestricted access to other tenants’ documents.

Run a harmless staging test matrix

• A permitted sample document uploads and becomes available only after the expected checks.
• An oversized file and a harmless file with a mismatched extension are rejected clearly.
• A second test account cannot download the first account’s attachment, including after changing an identifier in a URL.
• A scanner outage leaves the sample quarantined and creates a useful operator signal.
• Deleting an attachment removes access and follows the retention policy for originals and derivatives.

Use inert fixtures rather than live malware. Compare responses, permissions and storage paths; do not test a web shell on a production customer site.

Maintain the boundary after launch

Review supported formats when the business adds a new upload feature. Patch parsing libraries and monitor repeated rejects without retaining sensitive document contents in logs. Connect this work to safe application updates, a tested restore plan and incident response if unexpected executable files appear.