A form with attachments can make it easier to request a quote, process a return, submit an application, or report a technical issue. However, every received file opens a journey that does not end in the browser: it may pass through the web application, WordPress, storage, a support platform, a CRM, or an automation. If that journey is not defined, a legitimate attachment can cause operational errors or expose systems that were not prepared to receive it.
The goal should not be to accept any file and react afterwards, but to allow only the attachments that are essential for each process. This approach balances experience and protection: the user knows the rules before submitting the form, and the company has consistent controls for validating, storing, sharing, and deleting documents.
The problem is accepting more attachments than necessary
Not all forms need the same upload capability. A sales contact form may require an image or a PDF to assess a project; a return may need photographs; a job application may need a CV. By contrast, a newsletter sign-up form or a brief enquiry normally does not need files. Inventorying all upload points, including those created by plugins, private areas, and support tools, helps eliminate unnecessary attachments before adding technical controls.
OWASP recommends defence in depth: limiting extensions to those required for the business function, restricting uploads to authorised users where appropriate, setting size limits, and storing files outside the application’s public directory or on a separate host. These measures should be considered as a set, not as a single extension check. [1]
- Review contact, support, returns, job application, and private portal forms.
- Remove file uploads when a description, order number, or secure link resolves the process.
- Distinguish between public forms, authenticated forms, and internal processes.
Create an upload contract for each process
The most useful measure is to create a simple record for each form: the purpose of the attachment, accepted formats, maximum weight per file, maximum number of files, authorised people, storage destination, internal retention period, and process owner. This contract turns a generic “attach file” option into an operational rule that technology, marketing, and customer service teams can review together.
For a hypothetical example, a return form might accept up to three images to document a product’s condition, while a support form might accept a PDF or a screenshot. It is not advisable to copy the same limits for both cases: they should be based on what a person needs to provide to complete that request, the available technical capacity, and the tools that will receive the file afterwards.
- Document a brief justification for each permitted format.
- Define who can download each attachment and in what context.
- Assign an owner to review changes to plugins, integrations, or process requirements.
Validate in multiple layers and communicate clear errors
The extension seen by the user is not enough to decide whether a file is acceptable. The application should apply a short list of permitted formats, carefully handle anomalous or encoded names, check the type and, where appropriate, the file signature. It should also generate its own internal name instead of reusing the submitted name. This reduces reliance on data controlled by the person uploading the file. [1]
Limits must exist consistently in the browser, application, server, storage, and subsequent integration. OWASP identifies the absence of limits on size, time, memory, or operations as a risk, and also recommends limiting frequency according to the needs of each endpoint. When a request exceeds the allowed size, HTTP status code 413 can communicate that the server will not process it; the displayed message should indicate the maximum size or permitted formats without revealing internal details. [2] [3]
- Apply an individual limit and a maximum number of attachments per submission.
- Avoid processing or decompressing files without controlling the resources that task can consume.
- Explain how to correct the submission: for example, reduce the size or choose a permitted format.
Separate receipt, storage, and integration
A received file should not be publicly accessible or executable by default. It is preferable to store it outside the website’s public directory and provide downloads through a mechanism that checks permissions and the relationship with the relevant case. This separation is especially important if the website uses WordPress, an online shop, or third-party components: the convenience of directly linking to a file should not replace access control. [1]
Before forwarding an attachment to a CRM, help desk, or automation, confirm that only a file that has already been validated and associated with an operation identifier is transmitted. If the external destination fails, the flow should record the status and allow controlled recovery, without duplicating submissions or losing the link to the original request. In authenticated forms that change the application’s state, measures against forged requests should also be considered, such as tokens, origin validation, or other controls appropriate to the architecture. [4]
- Do not publish predictable URLs for downloading attachments.
- Maintain separate permissions for people who receive, review, and download documents.
- Test what happens if the CRM or support system does not respond.
Log, test, and improve without affecting the business
To investigate failures and incidents, log the when, where, who, and what of the event: request identifier, form, validation result, rejection reason, size, detected type, destination, and processing status. OWASP includes the upload and processing of user-supplied content among the relevant events for logging and monitoring. It is not necessary to store the attachment’s content in logs; doing so may increase exposure of sensitive information. [5]
Before enabling changes, test in an authorised environment or within an explicitly agreed scope. Use harmless files to verify a valid upload, an oversized file, a disallowed format, an anomalous name, and a simulated failure of the external destination. Afterwards, review the messages received by the user, the logs, and the process recovery. A web protection audit can help review this complete journey and prioritise defensive fixes without turning testing into a disruptive activity.
- Periodically review repeated rejections and delivery errors to external systems.
- Check that limits match across all technical layers.
- Update the upload record when the business process or an integration changes.
Frequently asked questions
Is it enough to block extensions such as .exe or .php?
No. Blocking some formats can be part of the protection, but it does not replace a list of necessary formats, file validations, internal names generated by the application, resource limits, non-public storage, and access controls for downloads.
What maximum size should I allow in a form?
There is no universal value. It should reflect the legitimate use of the form, the number of permitted files, processing capacity, and the limits of connected systems. The important thing is to apply a consistent rule and clearly explain the limit before or during submission.
Can I automatically send attachments to the CRM?
Yes, if the flow is designed so that the integration receives only files that have already been validated and can trace each operation. It is advisable to control permissions, record the delivery status, and define what happens if the CRM rejects the file or is unavailable.