Validate uploaded file types with explicit evidence
Compare allowed extensions, declared MIME types, and parser results. Build a bounded upload test set that checks mismatches without using live malicious files.
An upload endpoint should accept the formats a feature needs, not everything a client can label as a document. Start with the product operation: an avatar, a statement import, and a support attachment can require different formats and different downstream processing.
OWASP cautions against trusting the supplied Content-Type. The test set below compares several independent observations. Passing one observation does not establish that a file is harmless.
Define the accepted-format record
For each supported format, name the parser or processing library and the output the application expects. Record whether the original bytes will ever be served to another user. A format accepted for offline parsing does not automatically belong in an inline browser preview.
| Fixture | Declared type | Content observation | Expected disposition |
|---|---|---|---|
| Small valid permitted file | Matching type | Approved parser accepts | Continue to remaining checks |
| Renamed plain text | Claimed permitted type | Parser rejects | Reject without publication |
| Valid but unsupported format | Accurate type | Recognized outside allowlist | Reject with a clear reason |
| Truncated permitted file | Matching type | Parse incomplete | Reject and remove temporary data |
Create harmless fixtures specifically for the review. There is no need to download unknown malicious samples to test a filename or MIME mismatch.
Check the order of operations
Apply request and byte limits before expensive parsing. Keep the upload outside public serving paths while checks run. Record which component makes the final accepted-format decision and whether a later conversion can change the media type.
Test alternate upload routes, including direct-to-storage completion callbacks and administrative imports. A well-checked browser form does not cover a callback that trusts client metadata and marks an object ready.
Preserve useful rejection evidence
Return a bounded error that explains the permitted format without exposing parser internals. Log the internal upload identifier, rule, and parser version rather than the entire document. Confirm that failed uploads do not leave downloadable originals or orphaned conversion jobs.
Keep a valid fixture in every regression run. Otherwise a parser configuration that rejects every upload can appear secure. When changing libraries or adding a format, review the relevant fixture set and downstream serving behavior together. The acceptance record should show format agreement, successful bounded parsing, and continuation to the remaining authorization, quarantine, and storage checks rather than a blanket claim that the file is safe.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.
Sources
- OWASP File Upload Cheat SheetAccessed