Adding file uploads means deciding what you accept, where it is stored and who can retrieve it. A filename or extension does not prove a document is safe. Define limits, checks and a review route before forwarding or processing it, then test the complete journey with fictitious information rather than customer records.
What changes when an enquiry form accepts files?
A contact message describes a need; an attachment can include plans, photographs or records the business should not distribute indiscriminately. The work continues after the uploaded message appears. Someone must find the document, associate it with the right enquiry and determine which tools can open it. If the form only emails a copy, the organisation can easily lose track of where the information is retained.
Imagine a small architecture practice requesting a floor plan to assess a renovation. This is a hypothetical example. A prospective customer attaches one document and sends another later. Staff need to identify which version they are reviewing and avoid exposing either through a public link. Before building the field, define what is needed for the initial conversation and what should be requested only if the project proceeds.
OWASP's File Upload Cheat Sheet, accessed on 19 October 2026, recommends combined controls covering types, filenames, sizes, storage and processing. It does not provide a security badge obtained by enabling one option. Treat the file as untrusted input and ask the technical owner to explain the controls actually applied, including their limits. A reassuring label in a plugin is not an explanation of the journey.
Avoid asking for all available documentation merely because it is convenient. That transfers a business decision to the visitor. Explain the purpose and provide an alternative where the person cannot supply a file. In the hypothetical practice, a short description might be enough to decide the next contact. Asking for less can simplify reception and reduce the information the team subsequently needs to look after.
Why is allowing only PDF not enough?
The browser's visible control helps a person choose a format but does not replace server-side validation. OWASP's Input Validation Cheat Sheet explains that distinction. Calling a file plan.pdf does not establish its contents or safety. Neither the name nor the sender's declared content type provides that evidence on its own. The actual processing and storage design determines which additional checks are needed.
Select formats around the task. A team needing to view a floor plan should not automatically accept every archive or executable format. Define what the service allows and explain rejection clearly. Do not copy a long extension list from another form without establishing what staff can open appropriately. Broad acceptance can create more work than a precise, understandable request that fits the initial enquiry.
Size limits also need visible explanation. Visitors should not complete a long enquiry before discovering that their file is too large. Show the configured format and limit before submission, preserve their message if an error occurs and explain how to continue. The appropriate value depends on the task and technical capacity. This article does not prescribe one universal limit for every organisation or document type.
Distinguish validation failure from infrastructure trouble. A disallowed format differs from an interrupted save. The person needs to know whether to change the document or follow a provided retry route. Do not confirm complete receipt when the file is unavailable. Staff should recognise those cases without asking the customer to reconstruct the entire interaction by telephone or resend everything through an improvised channel.
Where should files live, and how is access authorised?
The storage location depends on the application and controls. OWASP recommends separating uploads from the application's served or executable area where appropriate to the design. For a business owner, one question matters: could someone without permission retrieve this document if they obtained its link? Do not assume an address is private merely because it is long or difficult to guess. The server needs to enforce the intended boundary.
OWASP's Authorization Cheat Sheet recommends checking permissions for each access and using a restrictive default. In the architecture example, someone reviewing an enquiry needs its documents; that does not make every case available to every account. Permission should fit a role and a case, rather than simply establish that a person once signed into the dashboard. Ask how that relationship is checked when a link is opened.
Decide what happens when a collaborator changes role or leaves. Review links in old emails and the access they retain. A downloaded copy is no longer controlled in the same way as the system's stored file. This does not prevent ordinary work, but does require a practical sharing and revocation procedure. Describe what staff actually do, not just what the initial access settings are intended to achieve.
Retention needs a separate decision: how long an enquiry that goes no further is kept, and who can request its removal. Do not borrow a deadline from an unrelated activity. Review purpose, obligations and operational need with whoever handles data protection. This is general information, not legal or professional advice. A consent checkbox does not automatically resolve every processing condition or authorise any later use of the document.
What happens before opening, forwarding or sending a file to AI?
The route may include scanning, previewing, email and automated extraction. Every step needs a purpose and an owner. Checks should not begin after the document has already been sent to several destinations. Identify which tool will receive the information and whether that transfer belongs to the service explained to the visitor. Do not experiment with external readers using real personal records simply to see whether they work.
OWASP discusses controls such as malware scanning or content reconstruction where appropriate, while emphasising a combination of measures. Ask what is assessed and what happens when a file cannot be checked. Pending review is more honest than safe when evidence is incomplete. An antivirus check should not be presented as a guarantee that every document can be opened without precautions or that the surrounding application is secure.
If AI extracts information, keep the document's contents separate from the instructions governing the tool. Receiving attachments does not itself require building another agent. A controlled manual route and an appropriate preview can be a useful starting point. Automation is worth investigating when there is a repeated need, an authorised environment and a clear criterion for the information expected from the file. More destinations are not automatically more useful.
| Stage | Useful evidence | Avoid |
|---|---|---|
| Submission | File associated with the enquiry | Confirming without retaining it |
| Validation | Type and limits checked | Trusting the extension alone |
| Retrieval | Authorised case access | A public link by default |
| Processing | Defined tool and purpose | Uncontrolled forwarding of copies |
How can you test without customer documents?
Prepare fictitious files of the expected kind. Include an acceptable document, one exceeding the configured limit and an unsupported format. You do not need to create malicious material to check basic feedback. A technical owner can design security tests in a controlled environment. Customer-facing staff should review whether the explanations let a visitor continue without losing the enquiry or wondering whether the submission was received.
Check that an account lacking case access cannot retrieve the document, while an authorised person can. Review the difference between replacing a version and adding a new attachment. The test should reach whoever works on the enquiry. A file appearing in a folder without a usable connection to a contact does not complete the business journey, even if the upload itself was technically successful.
Leave a short incident guide: how to recognise an incomplete upload, where to escalate a questionable document and what alternative to offer when attachment fails. Do not publish security claims without evidence from an appropriate review. A functional test establishes observed behaviour under its conditions. It does not certify the whole application or replace maintenance of the components that receive, display and process the file.
How have we approached it at meiika?
We study websites together with the process after submission. Requesting a document affects service, access and organisation. Before adding the field, we would need to understand what information the business actually needs and who will use it. The appropriate first step may be clarifying the request rather than expanding the upload options offered to every visitor.
Custom systems can connect the enquiry, document and responsible person. Here we describe review criteria, not an audit of a particular platform or a guarantee of uploaded-file safety. Scope depends on the existing tools, handling requirements and the people who will maintain the process once it is in use.