Follow the file after the upload completes
An upload feature includes acceptance, storage, processing, retrieval and deletion. Start by listing those stages and identifying the component responsible for each. A customer may upload a harmless-looking attachment successfully while the download path later exposes it to the wrong organisation. Review who can perform each action, not just which file extensions the form displays. Use synthetic files in an environment you are authorised to test.
Define a narrow acceptance policy
Specify the file types and sizes the product actually needs. Apply validation on the server and do not trust a browser-provided filename or content type alone. OWASP’s guidance describes multiple protective checks because no single signal establishes safety. Decide what happens when validation or processing fails. The customer should receive an understandable result while the system avoids leaving untracked or publicly accessible objects behind.
Use an attachment example
Consider a support portal where a customer uploads an invoice for a private ticket. Check whether another customer can obtain the attachment using a copied URL, whether an expired link still works and whether staff access is appropriate to their role. Record the intended behaviour before testing. A public object URL may be suitable for a product brochure; it is a different decision for a private invoice.
Exercise the lifecycle
Try a permitted file, an oversized file and a file that fails processing. Confirm that interrupted uploads do not accumulate indefinitely. Then close the ticket or delete the attachment and inspect what remains in the application and storage layer. Where retention is intentional, document who can still retrieve the object. A deleted database row does not, by itself, prove that the stored object has disappeared.
Keep evidence with the feature
Retain the acceptance rules, access decisions and lifecycle test results alongside the upload implementation. Include any external processing service in the data-flow diagram. Revisit the review when introducing previews, document extraction or public sharing, because those features add new paths. An independent assessment is most useful when it follows these transitions and explains the residual risk instead of treating the file picker as the entire boundary.
Sources & further reading
Reference material for the guidance and examples above. Where included, community discussions provide context rather than verified incident evidence.
Prepared with AI assistance. Examples are illustrative and are not client case studies.
About CodeSignOff Editorial
CodeSignOff Editorial publishes engineering guidance for founders evaluating AI-built software. CodeSignOff is a product of Avi Root Info Solutions, led by Shekhar Juneja, whose software career began in 1998 and includes architecture for UK mortgage and credit-rating systems. This organisational byline does not indicate a personal review of this article by Shekhar.
Engineering background and editorial approach · Shekhar’s professional profile ↗
Evidence to take into your own review
Define the code revision and scope. For each finding, record the affected flow, the steps that reproduce it, its business consequence and the evidence for the next action. After a fix, repeat the check and record what remains uncertain. An audit delivers a verdict; remediation and verification are separate steps.
This article is general engineering guidance. It does not establish the security or compliance of your application. Contact us with a correction or a question about the guidance.