Blog

File uploads in modern web applications—also in enterprise platforms like Mendix—often appear deceptively simple. A customer wants to upload an image, a document, or a design—nothing unusual. Behind the scenes, however, this simple act opens a surprising number of doors, some of them welcoming and others… less so. 

Consider a Mendix application that produces laser-engraved gadgets. Customers submit their own files, creativity flows freely, and every order begins with an upload. The convenience is obvious. The security implications, on the other hand, tend to hide in the shadows until one day they step into the spotlight. 

When “Almost Anything” Really Means Almost Anything

In such a scenario, restricting file formats is rarely practical. Images appear as PNG, JPG, or SVG. Designs travel as PDFs or even proprietary editor files. A service that engraves anything must often accept almost anything. 

The challenge starts when “almost anything” includes file types that carry risks. Files arrive as opaque blobs of data with no inherent structure or guarantees. An image may truly be an image, or it may be an executable wearing a friendly name. A document may contain nothing but text—or embedded macros waiting for the right moment to run. 

Client-side restrictions help guide well-intentioned users, but they offer no protection against deliberate misuse. Anything enforced only in the browser can be bypassed as soon as the browser is no longer part of the conversation. 

Once a system begins to trust file uploads without verifying them on the server, it risks becoming more than an application. It becomes a storage location for content it never intended to host. 

The Polite Sign on the Door 

Mendix applications commonly store user uploads in an entity inheriting from FileDocument, with files arriving through widgets such as the File Uploader or custom-built components. These widgets are often configured to restrict file types and sizes, providing immediate feedback when an upload does not meet the expected criteria.

In many real-world projects, this story unfolds inside an application. Mendix is built to make development feel less like wiring machinery and more like assembling proven components. Authentication, data models, and file storage come ready to use, allowing teams to deliver applications quickly. But speed can create a subtle illusion: that convenience equals safety. In reality, Mendix file uploads—just like in any web platform—are only as secure as the rules developers define around them. The platform provides the doors and locks; deciding how strictly they are checked is still up to the builder. 

From a functional perspective, this setup appears robust. From a security perspective, it is only the first layer. 

Strengthening File Upload Security in Mendix 

The real risk emerges once authentication is involved. When a user logs into a Mendix application, the runtime validates the credentials and creates a server-side session. This session is identified by a session ID, which is sent back to the browser and stored in a cookie. 

From that point onward, the browser holds everything necessary to authenticate future requests. Every file upload, data modification, or commit action is authorized through these session artifacts. 

The Mendix client becomes a convenience layer, not a security boundary. 

Modern browsers expose all HTTP traffic through developer tools. Within these tools, it is possible to inspect file upload requests in full detail. The request headers reveal the session cookie, the auth token, and the exact endpoint used to transmit files to the server. Object identifiers and request payload structures are also visible. 

Once this information is known, the same request can be reconstructed outside the application interface. Tools such as Postman or curl can send an identical HTTP request directly to the Mendix backend. The only difference is the file being attached.

Nothing Broke — and That’s the Problem 

At this stage, the upload widget is no longer involved. Any file can be submitted, including executable files, macro-enabled documents, or payloads renamed to appear harmless. As long as the session is valid and no server-side validation exists, the runtime accepts the request and persists the file. The server responds with a standard success code, and no error is raised. 

This behavior is not a vulnerability in Mendix itself. It is the expected result of trusting authenticated requests without additional validation. 

From the server’s perspective, the request is legitimate. The session is authenticated, the CSRF token is valid, and the entity is configured to allow file storage. Without explicit validation logic, there is no reason for the runtime to reject the upload. 

This transforms file uploads into a privileged attack vector. Any authenticated user gains the ability to store arbitrary files unless the application explicitly prevents it. 

A simple maneuver, yet powerful enough to plant malicious files inside the system. 

Strengthening the Server’s Gatekeeping 

To prevent unauthorized or dangerous files from entering, the server must perform its own checks. 

Using Event Handlers as a Control Point 

Mendix provides a built-in interception mechanism through Before Commit event handlers on entities that inherit from FileDocument. These handlers allow logic to run just before a file is persisted. 

At this point, the application can inspect the uploaded file and decide whether the commit should proceed. Common checks include evaluating the file extension, validating file size, or rejecting files that do not meet basic criteria. 

Looking Past the Filename  

A more robust approach involves examining the file’s MIME type, which identifies the format based on the actual content rather than the filename. Each file begins with a unique sequence of bytes, allowing more reliable detection of its true nature. 

In Mendix, MIME type validation can be implemented through a Java action—either custom-built or taken from the Marketplace. While MIME spoofing is theoretically possible, it is considerably more complex and offers much less value to attackers. 

Additional Security Layers 

No single validation step can fully secure a file upload. Effective protection emerges from combining several smaller, well-defined controls: 

• File size limits reduce denial-of-service risks and make certain attacks impractical. 

• Content-based validation ensures that a file’s internal structure matches its declared type. 

• Virus scanning helps catch known malicious payloads before they are stored or processed. 

• Rate limiting protects the upload endpoint from automated probing and abuse. 

• Clear validation messages improve application usability. 

Individually, these measures are useful. Applied together, they acknowledge an uncomfortable truth: uploads will fail eventually, and systems should be designed with that expectation in mind. 

The Curious Case of the SVG 

Among commonly accepted formats, the SVG is a special character. Although visually an image, internally it is an XML file capable of containing JavaScript. When opened in a browser, SVG files can render arbitrary content and execute scripts. 

In certain scenarios, this allows SVG files to imitate application interfaces, including login screens. When combined with social engineering, this can lead to credential theft. While this risk does not affect every Mendix application, it becomes relevant when files are opened directly in the browser. 

For this reason, applications with download features must treat SVGs thoughtfully, either sanitizing or disallowing them depending on the context. 

A Principle Worth Following 

In the world of file uploads, minimalism serves as a guiding principle: allow as little as necessary, and only as much as required. 
Client-side validation improves user experience. Server-side validation preserves trust. 

A simple upload button might start as a convenience feature. With the right precautions, it remains exactly that—safe, controlled, and ready to support everything from customer creativity to laser-engraved masterpieces.