Handling Security Findings Related to Data Exposure
Context
You may discover potential data exposure in your Mendix application. Protecting application data is a shared responsibility between the platform and the application development team. Within a Mendix application, access to data is controlled through entity access rules, module roles, user roles, and XPath constraints. If these are not configured correctly, users may unintentionally gain access to data that should be restricted.
Potential data exposure can be identified in different ways. You might discover it as part of a periodic security review, during a penetration test, through automated security scanning, or as a result of being contacted by an ethical hacker or security researcher.
In many cases, such findings are related to incorrect entity access configuration, overly permissive role mappings, or insufficient data constraints within the application. These are application-level configuration issues and are not vulnerabilities in the Mendix platform itself.
This document outlines the recommended steps to assess the situation, remediate the issue, and reduce the risk of similar problems in the future.
Understanding Mendix Data Security
Mendix applications consist of two parts: the Mendix Client, running in the end-user’s browser or mobile app, and the Mendix Runtime Server.
The Mendix Client communicates with the Runtime Server using the Mendix Client API, making requests to the /xas/ request handler on the Runtime Server. The Client API is built on the premise that requests from the client can’t be trusted to be safe or secure. As the client is running on the end-user’s device, outside of the control of the server, any data or action can be manipulated there. “Nothing that happens on the client can be considered secure” is a statement that applies to everything that is held on the client (for example, in a browser) not just to Mendix applications.
Therefore, in Mendix, security is always taken care of in the back end, the Runtime Server, with entity access rules and allowed roles on microflows. The Runtime Server cannot be manipulated by the end-user.
Verify the Vulnerability
When potential data exposure is identified, the first step is to determine the scope and impact. The development team should reproduce the issue and confirm which entities are affected and which user roles have access. Special attention should be given to the Anonymous user role and to any roles that may have broader access than intended.
It is important to verify whether the exposure is caused by missing or incorrectly configured entity access rules, incorrect module role mappings, insufficient XPath constraints, or custom logic such as microflows or published REST services that bypass expected checks.
To understand whether the issue may have been exploited, web server and infrastructure logs can be reviewed for unusual traffic patterns or unexpected data requests. However, standard web server logs do not provide detailed insight into specific /xas calls or the exact data retrieved. The Mendix runtime does not automatically create detailed data-access audit trails. If detailed auditing of data access is required, implementing such logging mechanisms is the responsibility of the application owner.
Remediation
After confirming the issue, we recommend the following actions to mitigate this.
- Entity access configuration should be reviewed across the affected application. Ensure that all entities have explicitly defined access rules aligned with the intended security model. Carefully validate module role mappings and confirm that XPath constraints properly restrict data visibility. Pay particular attention to permissions granted to anonymous users. If anonymous access is not strictly required, it should be disabled or tightly constrained.
- Consider upgrading to supported Mendix versions such as Mendix 10 LTS or Mendix 11 MTS where applicable, as these provide enhanced security features and improvements. During migration, perform a full review of security settings and access rules. Version guidance can be found in the Mendix documentation:
- Establish a security baseline tailored to your business requirements. This includes clearly defining access control standards, reviewing entity permissions during development, and validating security before each release. Best practices for secure development are available here:
- Consider implementing tools like the Ciphix Dev Tools, QSM (Quality and Security Management) or Omnext for security analysis.
Additional Support
If you have additional questions about application security configuration, or if you believe the issue may be related to the Mendix platform itself rather than application configuration, please contact Mendix Support.
For further information regarding this topic, please see: