Securing file uploads in ERPNext

Frappe lets administrators restrict which file types can be attached and how large an upload may be. These rules run when a file reaches the application, so they stop obvious mistakes such as executable files or oversized archives entering through standard forms and the Desk. They do not inspect what a file actually contains. A file renamed to a permitted extension passes the extension check, and a valid PDF can still carry malicious content. Confirm in your version where the allowed extension list and the maximum upload size are configured, whether the list applies to every upload path including API calls, and how your web server or reverse proxy limits request sizes, since a proxy limit can reject files before Frappe sees them.

• Extension allow lists: Limit uploads to the file types your processes need, and check whether the list is enforced on API and integration uploads, not only the Desk.
• Size limits: Set a maximum that matches real business documents, then confirm the same ceiling is applied at the proxy and in Frappe.
• Content blind spot: Extension and size checks do not detect malware, macros or polyglot files, so they are necessary but not sufficient.
• Bypass paths: Check whether data import, custom scripts or third-party apps can store files without passing through the standard upload handler.

Before go-live, test a renamed executable and an oversized file through each upload path your users and integrations actually use.

Access rules decide who can read an uploaded file once it is stored. Frappe distinguishes private files, which require an authenticated session with permission on the parent record, from public files, which can be fetched by anyone holding the URL. This layer stops casual browsing and accidental exposure of attachments to unrelated users, but it depends on correct DocType permissions and on the file being attached to the right record. It cannot tell whether a permitted user should be downloading a particular document, and it does not stop a user with legitimate access from forwarding a link. Confirm how your version assigns the private or public flag by default, whether guest users can upload or view any files, and which DocTypes expose attachment fields to website or portal users.

• Private by default: Confirm that new uploads are private unless a business reason requires public access.
• Guest uploads: Verify whether guest or website users can upload files, and restrict or disable that path if the form does not need it.
• Permission inheritance: A private file is only as protected as the parent record's permissions, so review role and user permissions on each DocType that accepts attachments.
• Shared links: Public URLs can circulate beyond the intended audience, so limit where public files are created.

Review a sample of attachments as a guest user and as a restricted internal user to confirm what each can open.

Content handling changes a file before or after it is stored, most commonly by removing embedded metadata such as EXIF data from photographs, which can contain GPS coordinates, device identifiers and timestamps. This matters when images come from customers, field staff or applicants. Whether ERPNext or a companion app strips EXIF automatically is a version and configuration question, so confirm it rather than assume it. Metadata removal does not address malicious payloads, does not change the document format, and does not affect what a file says. It also does not remove information inside documents such as author fields or revision history, which need separate handling if they are sensitive.

• EXIF and location data: Confirm whether images are stripped on upload or whether a separate step is required before storage.
• Document properties: PDFs and Office files can carry author, revision and comment data that metadata stripping for images will not remove.
• Format conversion: Converting files to a fixed format can reduce some risks, but it changes the record and should be agreed with the business owners who rely on the original.
• Retention of originals: Decide whether unstripped originals are kept, and who can reach them.

Test with a photograph containing known location metadata and confirm what is stored and what a downloader receives.

Malware and content scanning belong in a layer outside Frappe, usually a scanning service or a quarantine step between the upload point and the stored file. This layer is the only one of the four that can inspect file contents for known malicious patterns, which is the risk that extension and access rules cannot see. Its limits are equally clear: signature-based scanning misses new or targeted threats, it adds latency and operational cost, and it needs a decision on what happens to files that cannot be scanned, such as encrypted archives. Frappe does not provide this scanning as a built-in feature in the sources reviewed for this topic, so the design, vendor and quarantine workflow must be planned explicitly. Confirm the scanning product's update cadence, its handling of archives, and how quarantined files are released or deleted.

• Quarantine first: Hold new uploads in a separate location until a scan result is recorded, then release them to the record.
• Failure handling: Define whether unscanned or unreadable files are rejected, held or allowed, and document the choice.
• Archives and nesting: Confirm how the scanner treats compressed and nested files, which are a common way to hide content.
• Audit trail: Keep scan results and release decisions linked to the record for investigation.

In your environment, confirm the scanner's coverage with a test file set and confirm the integration point with your ERPNext deployment team before committing to a design.