Start with the business task
A customer attachment is a piece of untrusted input, even when the sender is a long-standing customer. A quotation form might need a drawing and photographs; a warranty claim might need a receipt. Write down the exact business purpose of each upload field and the file families needed to complete it. If a field has no clear use, remove it. This narrows what the service must parse, store and display. OWASP recommends an allowlist of extensions needed for business functionality rather than a general promise to accept any document.
Make the customer instruction specific: which file formats are accepted, what information must be visible, and what to do if a document cannot be uploaded. A service desk should not quietly encourage customers to email the same sensitive attachment to an unmanaged shared inbox when the form rejects it. Define an assisted route with the same access, retention and handling rules. The limits you choose are product decisions: a small photograph limit may block detailed drawings, while accepting giant archives makes review and capacity planning harder. Test with representative customer files before publishing the form.
Separate the need to submit a file from the right to read it. A public enquiry form may need to accept files without an existing account, but that does not mean submitted files should become public web assets. Give the upload a private case identifier and let only the assigned team retrieve it through an authorised application path. The resulting customer message should confirm receipt of the case, not expose a direct storage address. The design should also decide when an attachment is optional so a failed upload does not erase an otherwise useful enquiry.
Check more than the filename
A filename and browser-supplied content type are claims made by the uploader, not proof of a safe file. The server should decode and normalise the name before extension checks, reject ambiguous or dangerous names, and compare the claimed format with file structure where practical. OWASP notes that even signature checks can be bypassed, so none of these tests alone is sufficient. Keep the original customer-facing name only as carefully escaped metadata if staff need it; assign a separate application-generated storage name. Never let a customer-supplied path decide where the file lands.
Set limits at every stage that consumes resources: the incoming request, decompression, scanning, thumbnail generation and later download. A compressed archive can be small on arrival but costly to expand. If archives are not essential, exclude them. If they are essential, specify who may submit them, what contents are allowed, and how the system handles excessive expansion or deeply nested files. A failed scan or an unsupported parser must leave the file unavailable to ordinary staff; it should not silently become a successful upload because a scanner timed out.
Scanning and content disarm can reduce particular risks where they fit the file type, but neither is a universal guarantee. Decide which document formats require those steps and what the customer sees while processing continues. For example, an upload may be marked received but pending checks, with a later message if it cannot be used. That distinction matters to a customer facing a submission deadline. Record the reason for rejection in operational logs without echoing raw attack strings into a browser error or sending a suspicious attachment back to the customer.
Keep intake separate from staff access
Store new uploads outside the public web root or on a separate storage service, as OWASP advises. An intake record should connect the private file identifier, case, submitter, validation state and authorised readers. An employee clicking an attachment should pass a fresh permission check; a copied direct link should not become a permanent shortcut around case access. Use a controlled download response and safe content-disposition behaviour appropriate to the format. Avoid embedding active uploaded content in a privileged application page where it could run in the same browser context as staff tools.
Define the release condition in terms a team can observe. A file is usable only after the required validation has completed, the case permissions are in place, and the staff interface shows an unambiguous status. If any step fails, show the case owner what to do next without exposing the suspect file. A manager may choose to request a safer format or review an exception through a separate, restricted process. An exception should identify who approved it, why the standard route failed and which temporary safeguards apply; otherwise the exception quietly becomes the normal route.
File retention needs an owner as well. Decide when to delete rejected files, abandoned uploads and attachments for closed cases under the organisation’s actual records policy. Deletion should cover the stored object and the application reference; otherwise a “deleted” case may leave a reachable file behind. Conversely, if a dispute or legal hold requires preservation, the workflow must prevent routine cleanup until that hold is resolved. The article cannot set a universal Hong Kong retention period for every type of customer document; the correct period depends on the underlying record and obligation.
Walk through a realistic claim
Consider a retailer whose warranty form accepts a receipt image and a short description. A customer submits a photograph with an ordinary name; the service records the claim, checks the file against its allowed image formats and size limit, stores it privately, scans it where available, and then marks it ready for the service team. This is an illustrative workflow, not an observed retailer or a claim that a scanner makes the file harmless. The customer receives a case reference and a clear status. The agent opens the image through the case, not through a public URL.
Now try three adverse variants in a test environment. First, rename an unsupported document with an allowed image suffix; the intake should reject it rather than trust the suffix. Second, submit a legitimate image that exceeds the published limit; the customer should get a usable correction path while the textual claim remains available if the product allows it. Third, interrupt scanning or storage; the file must remain pending or failed, never silently ready. Each result should be visible to the right operator so the customer is not left waiting for a review that cannot begin.
Ask a colleague outside the project to follow the staff path using a test account with fewer permissions. They should not retrieve a file from another claim by changing an identifier, reusing a copied link or viewing a rejected item. Then ask the case owner to find a usable attachment and explain its status without needing a developer. This checks both security and operational clarity. Capture the observations as acceptance evidence, including which environment and file formats were tested; a diagram alone does not prove the deployed behaviour.
Agree the acceptance boundary
Before commissioning or changing an upload feature, write one short intake specification with the allowed formats, size and count limits, access roles, validation states, customer messages, retention owner and exception route. Make the developer show a file’s journey from receipt to deletion. The business owner should approve the trade-off between customer convenience and handling cost; the engineer should explain which checks are actually implemented. A claim that files are “securely uploaded” is too vague to test. This specification can become a compact acceptance checklist for a supplier or an internal team.
Choose the first release around the smallest useful set of formats. Review failed submissions and support requests after launch, separating genuine customer needs from hostile or malformed traffic before changing limits. A repeated request for a new format may justify a designed processing route; it is not a reason to bypass checks by telling staff to open email attachments. Any new parser or previewer expands the processing surface and needs its own tests. Update staff instructions and customer guidance together, so the visible promise matches the actual file handling.
For an SME, the immediate decision is whether the current form has a defensible boundary. Try one valid file, one disguised file, one oversized file and one interrupted processing path, then inspect what the customer and a limited-permission staff account see. If the organisation cannot say where a file waits before release, who can open it or how a rejection is handled, pause expansion of accepted formats and resolve those gaps first. This creates a useful baseline for later improvements without pretending that any single control can eliminate upload risk.
Before you proceed
- Can a customer tell received from ready?
- Can a restricted staff account reach only its cases?
- Does a failed scanner leave the file unavailable?
