1. A familiar problem on a larger scale
February 2026. The DIVD publishes a report on more than 2,000 Mendix applications that expose sensitive data to the public internet. No sophisticated attack. No zero-day exploit. Just a browser and a bit of curiosity. The only thing missing? Proper configuration.
What’s even more troubling is that this wasn’t the first time. The DIVD had already conducted the same investigation in 2022. At that time, organizations were notified. The vulnerable apps were patched. The problem was solved. Until the next time.
That raises a question: if the problem is known, the solution is documented, and the tools are available, why does it keep coming back? The answer isn’t technical. It’s organizational. In many Mendix teams, security is treated as a final check, not as an integral part of the development process. And skipping a final check? That happens faster than you think.
In this blog, we’ll take a look at exactly what the DIVD found. Why these kinds of misconfigurations are so persistent. And more importantly: how to set up your security so you can face the next DIVD audit with confidence. The fundamental question: are you in control?
2. The root of the problem is not the system
The Mendix security model is essentially simple.
A Mendix app consists of two layers:
- Mendix Client: runs in the user’s browser
- Mendix Runtime Server: runs on the back end
The client communicates with the runtime via the /xas/ request handler, the Mendix Client API. Everything you see on the screen comes through that channel.
The security logic resides exclusively in the runtime.
Entity access rules, module roles, user roles, and XPath constraints determine what a user is allowed to retrieve and view.
Mendix is explicit about this: by definition, the client cannot be trusted. Anything running on the user’s device is beyond the server’s control.
That is not a shortcoming of the platform. It is a deliberate architectural choice—and a sound one at that. In fact, it is one of Mendix’s strengths compared to alternatives.
The problem arises when those server rules are not configured properly.
Then the runtime obediently returns data where it shouldn’t. No exploit needed. No special knowledge required. A simple /xas/ call is enough.
It’s not a hack, it’s a “feature”.
In practice, the DIVD identified recurring patterns:
- Anonymous users with read access to private entities
- Module roles that are too broadly defined
- Missing or incomplete XPath constraints
- Microflows that quietly bypass access controls
The consequences are clear. Exposed names. Address information. Customer files. Internal documents. Sometimes identification documents. GDPR risk. Risk of fraud and phishing. Reputational damage.
And the most insidious part: abuse is nearly impossible to detect. A /xas/ call from a malicious actor looks exactly the same in the logs as a call from a regular user.
The irony? Mendix’s security model works exactly as it should. The problem isn’t with the platform. It’s in the process.
3. How to do it the right way
The good news is that this pattern can be broken. But not with a one-time fix.
Security must be an integral part of the entire development process, not just a checkpoint at the end.
The Software Development Life Cycle (SDLC) provides a natural framework for this. At every stage, there are choices to be made that structurally reduce risk.
3.1 Design: least privilege as a starting point
The first choice is the most important one. By default, no access, unless explicitly granted. Not the other way around.
That sounds obvious. But in practice, it’s tempting to start broadly during the modeling phase and then restrict access later.
However, nothing is as permanent as a temporary solution.
Least privilege means that for every new entity, you ask: who is allowed to see this, and under what conditions?
That question belongs in the design discussion. Not in the post-mortem.
For teams on Mendix 10.12 or higher, there is also Strict Mode. It limits what the client can request, regardless of the access rules. It thus acts as a safety net behind the configuration.
It’s not a substitute for proper settings, but it is a useful second layer.
3.2 Coding standards: security as part of the Definition of Done
An entity without access rules is not just a half-measure. It’s an open door.
Explicitly include security in the Definition of Done for user stories that require a change to the domain model. Then it becomes not an oversight but a completion criterion.
No user story is complete without having gone through the access rules, module role mappings, and XPath constraints.
Combined with peer review, four eyes on every security-sensitive change, this becomes a structural brake on creeping misconfiguration.
3.3 Testing: Automated Validation
Access rules can be tested automatically. For example, using Menditect.
This is optional, but it significantly bridges the gap between peer review and release checks.
A failed test due to a missing access rule? That’s always better than a notification from DIVD.
3.4 Release: The Outside-In Check
Before every production deployment, it’s worth accessing the app as an anonymous user. What is visible from the outside?
The most thorough approach is a penetration test, in which a security specialist systematically attempts to gain access to data they shouldn’t be able to see.
For teams that don’t perform this with every release, menscan.io is a quick and accessible alternative. It uses the same Mendix Client API as the browser and simulates exactly what an attacker without login credentials would see. Among
other things, it checks for:
- Anonymous access
- Demo users who are still active in production
- Exposed metadata
Little time. A lot of preventive power.
3.5 Governance: Continuous Feedback
A one-time check at release isn’t enough. Authorization drift occurs between releases: new modules, copied configurations, silent role changes.
Blue Storm’s AppControl continuously monitors the entire Mendix portfolio. It scans both the project model and deployed apps. It enforces centrally defined security policies through pipeline checks. And it flags drift before it reaches production.
Combined with a periodic access review, especially after team changes or major functional expansions, governance becomes a key feature of the landscape.
Conclusion
The DIVD report is no cause for panic. It is not a platform error. There is no urgent patch. You do not need to take your app offline. But it is a warning sign. A reminder that security does not automatically remain robust as an application grows, a team changes, or a deadline approaches.
The approach is not complicated:
- Least privilege as a guiding principle in design
- Security as an integral part of the Definition of Done
- An outside-in review for every release
- Ongoing governance of the portfolio
None of these measures is particularly burdensome. Together, they form a process that catches misconfigurations before they reach production.
Trust in your team and the agreements you’ve made is a strong foundation. Continuous governance is better.
Mendix gives you the right tools to build secure apps. What does the DIVD demonstrate (once again)? That having those tools isn’t the same as using them properly.
The difference isn’t in the platform. It’s in the process.
