What does Menscan scan for in Mendix applications?

Menscan scans for Mendix version information, development mode status, default credentials (MxAdmin:1), demo users with passwords, exposed constants containing API keys and secrets, API documentation endpoints, and domain model access control misconfigurations including entity permissions and attribute editability.

What is the difference between authenticated and unauthenticated Mendix security scans?

Unauthenticated scans work without login credentials and only function if Anonymous access is enabled in the Mendix app. Authenticated scans require a valid __Host-XASSESSIONID cookie from a logged-in session, which reveals more data based on what that session can access, including detailed domain model information and user permissions.

Is Menscan safe to use for Mendix penetration testing?

Menscan is a passive scanning tool that does not attack or modify anything. It adds an X-Scanned-By: Menscan header to all requests for transparency. No scan data or credentials are stored by the API. It is designed as a helper tool for manual security testing alongside code reviews and business logic analysis.

What Mendix security misconfigurations can Menscan detect?

Menscan detects demo users with exposed passwords that can lead to privilege escalation, constants containing API keys and secrets, exposed API documentation endpoints, development mode being enabled in production, default MxAdmin credentials, and domain model access control issues where users can read or write attributes they should not have access to.

What is the Menscan Authorisation Matrix?

The Authorisation Matrix compares several Mendix sessions side by side. You supply one URL and up to six session IDs, and Menscan probes every role against every entity the app exposes, reporting read, create and write access for each. An anonymous column is always included as a baseline. It is built for answering which roles can reach data they should not, without reading six separate scan reports.

Why does the Authorisation Matrix show a question mark instead of allowed or denied?

Some permissions cannot be established from the outside. A Mendix XPath query against an entity that does not exist returns exactly the same response as a readable but empty entity, so an empty result can never prove read access. Non-persistable entities cannot be queried by XPath at all. Write access cannot be judged without an object to inspect. In those cases Menscan shows undetermined rather than guessing, because rendering an unknown as a denial would put a false finding in your report.

How does Menscan find and execute Mendix microflows?

Mendix exposes callable microflows through the XAS runtime endpoint. Menscan queries this endpoint to enumerate all microflows the current session can invoke. For each discovered microflow, Menscan can attempt execution directly by sending a request to /xas/ with action 'executeAction'. If access controls on the microflow are misconfigured, any user (including anonymous or low-privilege users) can trigger business logic that should be restricted, such as admin actions, data exports, or account management operations.

Menscan Documentation

How to run a Mendix security scan with Menscan, what each section means, and how to act on the findings. New to Mendix security? Start with the Mendix security overview.

No data is stored. The API doesn't save scan results or credentials.

What Menscan Is (and Isn't)

Menscan is a focused scanner for Mendix applications. It speaks the Mendix XAS runtime protocol, so it sees the things general web scanners miss: demo users in session data, exposed constants, entity-level access control, callable microflows, and runtime configuration like development and strict mode.

It is a helper tool for manual security testing, not a turnkey vulnerability scanner. It does not attack, modify, or persist anything. Every request carries an X-Scanned-By: Menscan header so the activity is transparent in the target's logs.

Use it alongside code review, business logic testing, and a normal pentest workflow. For background on what these findings actually mean, see the Mendix security guide.

Scan Modes

1. Unauthenticated Scan

No login needed. Only works when Anonymous access is enabled in the Mendix app. Even without anonymous access you can still pull version, exposed endpoints, and a default-credentials check. More tricks in Pentesting Mendix Notes.

2. Authenticated Scan

Authenticated scans reveal more of the domain model and let you exercise role-bound access controls. Steps:

Log into the Mendix app in your browser
Open DevTools (or Burp) and inspect the cookies
Copy the __Host-XASSESSIONID value
Paste it into Menscan when starting an authenticated scan

Authenticated scans only see what that session is allowed to see. To map the full access surface, compare several roles at once with the Authorisation Matrix below.

3. Authorisation Matrix

One URL, several sessions, one grid. Instead of running a scan per role and diffing the reports by hand, paste a session ID for each role and Menscan probes all of them against every entity the app exposes. Steps:

Log in as each role you have access to, in separate browsers or private windows so the sessions do not overwrite each other
Copy the __Host-XASSESSIONID value from each one
Open Auth Matrix, paste the URL, and add one row per session
Label each row (Manager, Employee) if you want, though the app's own role names are detected either way

Up to six sessions per run. An Anonymous column is always added from a fresh session, so every role is read against an unauthenticated baseline. Expired sessions are dropped automatically, which matters because Mendix silently downgrades a dead session to anonymous rather than rejecting it, and an empty column otherwise looks identical to a genuinely locked-down role.

How to Run a Scan

The full flow from opening Menscan to acting on the findings.

Pick the target and mode

Open Start Scan, paste the full URL (including https://), and decide whether to toggle Authenticated Scan.

Supply session credentials (if authenticated)

Paste the __Host-XASSESSIONID value. Optionally provide a custom auth header name if the app uses a non-default cookie.

Run the scan

Menscan streams progress in real time and gives you the results in a tabbed view once it finishes. Typical scans complete in seconds.

Review System Information

Mendix version (and whether it's LTS/EOL), development mode, strict mode, default credentials, debugger endpoint, and exposed API documentation surfaces all live here.

Inspect Metadata

Browse the domain model. Editable fields are highlighted, look for sensitive attributes that should not be writable by the current role.

Enumerate Microflows

Discover callable microflows and test whether restricted business logic (admin actions, data exports, integrations) can be invoked.

Review Constants & Demo Users

Exposed constants frequently contain API keys, secrets, and webhook URLs. Demo users with stored passwords often grant elevated access in seconds.

What Each Tab Shows

System Information

Mendix version + LTS/EOL status
Development mode
Strict mode
Debugger endpoint exposure
Default credentials check (MxAdmin:1)
Exposed API documentation paths

Demo Users

Whether demo users are enabled
Usernames and passwords (when extractable)
Quick privilege-escalation path if exposed

Constants

Every constant the session can read. Often contains API keys, webhook URLs, and other secrets that should not be reachable by non-admins.

Plugins

Lists Mendix modules and widget plugins detected. Useful for spotting third-party components with known issues.

Metadata

The domain model: all entities, attributes, and which ones the current session can read or write. Editable fields are highlighted. Use the in-table search to filter records.

What to watch for:

Sensitive attributes editable by low-privilege users (e.g. is_admin, UserRoles, Email)
Wide read access on entities containing PII, payment data, or credentials
Create rights on entities that should be admin-only

Microflows

Microflows are Mendix's server-side business logic. Menscan enumerates the microflows the current session can invoke via the /xas/ runtime endpoint, then optionally executes each one directly using "action": "executeAction". If access controls are misconfigured, any user, including anonymous, can invoke restricted business logic without touching the UI.

What to watch for:

Admin actions exposed (password resets, account unlocks, role changes)
Data export microflows allowing bulk export to CSV or external systems
Anonymous-callable microflows where business logic runs without authentication
Integration triggers that call external APIs, send emails, or write to third parties

Reading the Authorisation Matrix

Every cell carries three badges, one per permission. Delete is never probed, because there is no way to test it without destroying data.

R, read

The role can query the entity. The row count next to the badges tells you how much it can actually see.

C, create

The role can instantiate a new object. Nothing is committed, so no record is written to the target.

W, write

At least one attribute is editable rather than read-only. This is usually the badge worth chasing.

A dashed question mark means undetermined, not denied. Mendix returns the same response for an entity that does not exist as for one you may read but which happens to be empty, and non-persistable entities cannot be queried at all. Menscan says so rather than guessing, so you never put a fabricated denial in a report.

Differs between roles

Entities where at least one role has different access from the others. This is the interesting list. On a real app most entities are identical for everyone, so a handful of rows here is normally the whole story.

Identical across all roles

Folded away by default and split into entities every role can reach and entities no role can reach. Expand it when you want the full picture. An entity that every role including Anonymous can read is still worth a look, even though nothing differs.

Runtime operations

Which callable operations each role is offered. Mendix exposes no microflow names over the wire, only operation IDs grouped by their parameter and association signature, so that signature is what labels each row. A role being offered an operation the others are not is a lead worth following in the Microflows tab of a normal scan.

Every role is probed against the union of all entities, not just the ones its own session advertises. That is deliberate: if one role is told about an entity and another is not, the question worth answering is whether the second is genuinely denied it or merely not informed of it.

I've Been Scanned. What Now?

Every Menscan request carries the header:

X-Scanned-By: Menscan

Search application logs around the scan time
The scanner is passive and does not attempt exploitation
It is a research tool, like any tool, it can be misused
Owners of misuse, not the maintainer, are responsible

Scanning Best Practices

Get useful results without burning the target or your own time.

Always confirm you have authorization to scan the target

Start with an unauthenticated scan to baseline the anonymous attack surface

Collect a session ID for each role you have access to (regular user, manager, admin)

Use the Authorisation Matrix to compare roles in one pass instead of diffing separate scans by hand

Note the Mendix version and cross-check known CVEs before manual testing

Treat exposed constants, demo users, and editable sensitive attributes as priority findings

Capture screenshots of Metadata and Microflow findings for your report

Combine Menscan output with manual business-logic testing and code review

Ready to Scan?

Paste a Mendix URL and Menscan handles the rest. Read the Mendix security guide first if you want the why behind each check.

Start Free Security Scan Compare Roles in the Auth Matrix Read the Security Guide