What the DIVD warning means for Mendix teams
In this article
Summary
In the past few days, the Dutch Institute for Vulnerability Disclosure (DIVD) published a warning about unintended data exposure in applications built with Mendix.
The key detail about the finding: this is typically not a vulnerability in the Mendix platform itself. It is a pattern of authorization misconfiguration that can expose data to the wrong users.
Mendix, a Siemens business, is an industry-leading low-code application development platform for the enterprise.
If you build or run Mendix applications, this is a good moment to check your landscape. It is also a reminder of a bigger point: low-code moves fast, and your guardrails need to move at the same pace.
We help Mendix teams stay in control at scale. In Mendix QSM, we work with Mendix to translate real-world risk patterns into checks that highlight overly permissive access settings early, keeping delivery fast and exposure risk down.
Low code is still on the rise
Instead of the technical coding environment required by traditional development, low code abstracts and automates every step of the software development lifecycle (SDLC) in an intuitive, model-driven, drag-and-drop IDE.
Low-code and no-code platforms are reshaping how organizations build and ship software. Gartner estimated that last year, 70% of applications were built using low-code or no-code tools, up from less than 25% in 2020.
As we wrote in our State of Software 2025 report, these platforms promise faster development cycles, greater business agility, and improved collaboration between IT and business teams.
But while the benefits are clear, the security risks are still often overlooked.
Here’s what to check based on DIVD findings in Mendix apps
DIVD describes common ways data becomes unintentionally accessible in Mendix apps, including:
- Entity access rules that are too permissive
- Incorrect role mappings
- Missing or overly broad XPath constraints
- Overly permissive rights for anonymous or default/new users
Dutch media reported that DIVD identified 2,000+ publicly reachable Mendix environments with risky configurations. Again, the emphasis is on configuration and authorization design, not a platform exploit.
Why this happens
Authorization rarely breaks in one big dramatic moment. It’s usually small, well-meant changes: someone opens access to troubleshoot a user issue, a temporary role sticks around after a release, a module gets reused with broader permissions than intended. After a few sprints, nobody remembers what changed—only that the app still ‘works’.
Pointing fingers doesn’t help. The practical fix is to make these checks routine, so risky access settings get spotted quickly and corrected before they reach production.
A quick self-check for Mendix owners
If you own a Mendix landscape (or even one app), start here:
- Review access for anonymous and default users
Make sure only truly public data is accessible without authentication. - Validate entity access rules
Look for entities with broad read access, especially around personal data, financial data, and customer records. - Re-check role mappings and XPath constraints
Misaligned roles and weak constraints are a frequent root cause of unintended exposure. - Enable a safety net where possible
Mendix documents “strict mode” as a way to make apps more secure when access rules are not configured correctly.
The real challenge: point-in-time reviews don’t scale
Penetration testing and manual reviews help. But they are snapshots.
We often see that security is viewed as a last line of defense, rather than an ongoing commitment. This approach can leave systems vulnerable and make repairs costly.
A frequent misunderstanding is the belief that conducting penetration tests equates to being secure.
Although penetration testing (pentesting) plays a crucial role, it generally takes place later in the development process. By that time, any vulnerabilities found may have already caused harm or necessitated expensive corrections.
Most authorization issues show up between those moments. Someone changes a role. A module gets reused. A new integration lands. The app is still “secure” in everyone’s mind, but the configuration has shifted.
What teams need is continuous control: checks that run repeatedly, highlight risky patterns, and make it easy to act without slowing delivery.
How we help: continuous visibility with Mendix QSM and Sigrid®
“The good news is this risk is preventable. Last year we added Mendix-focused security checks to the QSM ruleset that flag common authorization misconfigurations early, so teams get visibility when an app’s access settings become too permissive.”
Software Improvement Group (SIG) partners with Mendix on Quality and Security Management (QSM). QSM is designed to catch issues that lead to security incidents in practice, including entity access misconfiguration.
Sigrid® supports that approach at portfolio level. It helps you keep oversight across your application landscape so you can move fast without losing control.
What this looks like in real life
Instead of waiting for the next audit or pentest, teams get:
- Early signals when access patterns become overly permissive
- Repeatable checks that reduce “authorization drift” risk
- A clearer discussion between platform owners, security, and delivery teams based on shared facts
What do do next
If you are unsure whether your Mendix apps have configuration drift, start with a simple goal: prove that sensitive entities are not reachable by anonymous or broad default roles.
If you want an independent view across your Mendix landscape, we can help you set up continuous checks and prioritize the fixes that reduce exposure risk without slowing delivery.
Get an independent review of your Mendix landscape configuration risk.