Threat Model a File Upload Feature Before Building It

A file upload crosses several trust boundaries: a user-controlled client, an application server, storage and possibly a parser or preview service. Checking the extension is only one small part of the design. A threat model helps identify what must remain true before choosing implementation details.

Draw the data flow and identify assets

Consider a learner submitting a PDF assignment. The client sends the file to the API, the API stores it, a worker extracts a preview, and an instructor downloads it. Assets include the submission, other learners’ documents, server resources and account permissions. Mark which components accept user-controlled data.

Browser -> Upload API -> Quarantine storage
                         -> Validation/processing worker
                         -> Accepted storage -> Authorized download

Questions at each arrow:
Who may send data?
What is trusted?
What size and type are allowed?
Who may read the result?
How is failure recorded?

Validate content and naming independently

A client-supplied MIME type or extension can be misleading. Define allowed formats and use appropriate server-side validation. Generate storage names rather than trusting uploaded paths, and retain the original display name only as metadata handled safely. Avoid exposing uploads as executable application content.

Bound processing work

A small compressed file may expand into a large workload, and document parsers can consume substantial memory or CPU. Set limits on upload size, processing time, decompressed size where relevant and concurrent jobs. Define how rejected or failed files are cleaned up without losing an audit trail.

Authorize downloads as carefully as uploads

An unpredictable URL is not a substitute for access control. Check that the requesting user can read the specific submission. If using signed links, consider expiration, sharing behavior and whether cached responses could expose private content. A successful upload must not accidentally make another learner’s documents discoverable.

Turn threats into testable requirements

Write tests for disallowed types, duplicate names, oversized input, interrupted processing and cross-account access. Antivirus or scanning can be one layer, but a clean scan does not establish that every parser is safe. Keep dependencies maintained and separate untrusted processing from sensitive application privileges.

Practice and check your understanding

Write five requirements for the assignment workflow and a failure test for each. Include one authorization case, one resource-exhaustion case and one cleanup case. Review the design with someone who did not draw the original flow.

Continue learning

Explore the related Code Hacker course syllabus for structured learning. Then read HTTP Security Headers: Inspect and Understand a Response to connect this exercise to the next skill.

Reference

OWASP File Upload Cheat Sheet provides the underlying API or technical guidance. Check the documentation for the version you use; examples here are small learning exercises rather than complete production implementations.