Mendix Security
Everything you need to know about securing Mendix applications. Common vulnerabilities, misconfigurations, and how to test for them.
Why Mendix Security Matters
Mendix is one of the most widely adopted low-code platforms, used by enterprises to rapidly build and deploy business applications. But speed of development often comes at the cost of security. Mendix applications handle sensitive data like customer records, financial transactions, and internal business logic. A single misconfiguration can expose all of it.
Traditional web application scanners like Burp Suite or OWASP ZAP are designed for conventional web apps. They don't understand Mendix's unique architecture: the XAS runtime, entity-level access controls, session metadata exposure, or the way microflows handle business logic. This gap means Mendix-specific vulnerabilities often go undetected during standard penetration tests.
Understanding Mendix security requires knowledge of how the platform works under the hood. How it exposes data through its runtime API, how access controls are configured at the entity and attribute level, and where common misconfigurations occur.
Common Mendix Security Vulnerabilities
1. Default Credentials Left in Production
Every Mendix application ships with a default administrator account: MxAdmin with password 1. Developers are expected to change this before deploying to production, but many don't. An attacker who discovers this has full administrative access to the application, including the ability to modify data, change user roles, and access all business logic.
2. Demo Users with Exposed Passwords
Mendix has a built-in demo user feature that stores usernames and passwords in the client-side session data. When enabled in production, anyone can extract these credentials and log in as any demo user. Since demo users are often configured with different roles (Administrator, User, Manager), this frequently leads to privilege escalation. An anonymous visitor can become an admin in seconds.
3. Exposed Constants Containing Secrets
Mendix constants are configuration values that developers use to store API keys, database connection strings, webhook URLs, and other sensitive data. By default, constants can be read by any authenticated user through the runtime API. If anonymous access is enabled, these secrets are available to anyone. This can lead to third-party API abuse, lateral movement into connected systems, and data breaches.
4. Domain Model Access Control Issues
The domain model defines every entity (database table) in a Mendix app and controls who can read, create, update, and delete records. Misconfigured access rules are the most common and most dangerous Mendix security issue. When an entity like Administration.Account has writable attributes, any user can modify fields like IsActive, UserRoles, or Email. That opens the door to account takeover, privilege escalation, and data tampering.
5. Unrestricted Microflow Execution
Microflows are Mendix's server-side business logic. They handle everything from data validation to email sending to external API calls. Mendix exposes callable microflows through the /xas/ runtime endpoint. If access controls on microflows are misconfigured, any user (including anonymous sessions) can trigger admin-only actions like password resets, bulk data exports, account management, or calls to external systems. This is essentially remote code execution through business logic.
6. Exposed API Documentation and Endpoints
Mendix applications often expose documentation endpoints like /rest-doc/, /odata-doc/, and /ws-doc/ in production. These reveal the full API surface of the application: every REST endpoint, OData service, and SOAP operation. That gives attackers a complete map of available functionality. Combined with Swagger/OpenAPI specs, it becomes trivial to discover and exploit data access endpoints.
7. Development Mode in Production
Mendix applications running in development mode expose additional debugging information, detailed error messages, and sometimes the debugger endpoint itself at /debugger/. This helps attackers understand the application's internals and craft targeted exploits. A production application should never run in development mode.
Known Mendix CVEs
Several CVEs have been published affecting the Mendix runtime. These are version-specific and can be detected by checking the runtime version of a Mendix application.
| CVE | Description | Severity |
|---|---|---|
| CVE-2023-30548 | Allows bypassing of access rules for specific entities | High |
| CVE-2023-46170 | Information disclosure through error messages | Medium |
| CVE-2023-49069 | Bypass of entity access control rules | High |
| CVE-2024-21681 | Remote code execution via crafted expressions | Critical |
Running an outdated Mendix version exposes applications to these known vulnerabilities. Regular updates and version checks are essential to maintaining Mendix security.
How to Test Mendix Security
Testing a Mendix application for security issues requires a different approach than testing a traditional web app. Here's how to go about it.
Reconnaissance: Identify the Runtime Version
Start by figuring out which Mendix version is running. Check for known CVEs and whether the app is on an LTS release. Also check if development mode is enabled and whether the debugger endpoint is accessible.
Authentication Testing: Default and Demo Credentials
Test for the default MxAdmin:1 credentials and check whether demo users are exposed. Extract any demo user credentials from session data and try logging in with each to verify privilege levels.
API Surface Mapping
Enumerate all exposed API endpoints: REST services, OData feeds, SOAP operations. Parse Swagger/OpenAPI specs and OData $metadata documents to understand the full data surface available through APIs.
Domain Model Analysis
Retrieve the entity metadata to understand the full data model: every entity, attribute, and association. Identify which fields are readable and writable by the current user. Look for sensitive entities with overly permissive access rules.
Data Access and Manipulation
Use XPath queries to retrieve data from exposed entities. Attempt to modify editable fields on sensitive entities. Test whether new entities can be created without proper authorization. This is where you find the real impact: account takeover, data tampering, and privilege escalation.
Microflow Enumeration and Execution
Discover all callable microflows and test whether restricted business logic can be invoked by lower-privilege users. Admin actions, data exports, and integration triggers are common high-impact findings.
Constants and Configuration Review
Extract exposed constants and review them for API keys, secrets, database credentials, and other sensitive configuration values that shouldn't be accessible to regular users.
Why Standard Scanners Miss Mendix Vulnerabilities
General-purpose security scanners are built to test traditional web applications. They crawl HTML pages, submit forms, and test for SQL injection and XSS. Mendix applications work differently. The frontend is a single-page application that communicates with the backend through a proprietary runtime API (XAS), not conventional REST endpoints.
This means standard scanners can't see the real attack surface. They won't check for demo users in session data, they won't enumerate entity access controls through the metadata endpoint, and they won't test microflow authorization. Mendix security testing requires Mendix-specific tooling that understands the platform's runtime behavior.
That's exactly why Menscan was built. It automates the Mendix-specific checks that penetration testers would otherwise have to do manually, every time they encounter a Mendix application.
Mendix Security Hardening Checklist
If you're a Mendix developer or administrator, use this checklist to improve the security of your application.
Test Your Mendix Application Security
Menscan automates these security checks for you. Scan your Mendix application for default credentials, demo users, exposed constants, access control misconfigurations, and more. It takes seconds. Read the documentation to learn how it works, or start scanning right away.