Insecure user roles
Mendix gives you role-based access control out of the box, and the risk sits in how you use it. Roles that are drawn too wide hand people rights their job never asked for, and the damage does not look like an attack: it looks like an ordinary user opening a page, a record or an admin function that was never meant for them.
How this shows up in a Mendix application.
Administrative module roles on ordinary users
An admin module role ends up in a user role that normal employees hold, usually because it was the quickest way to make something work during a sprint.
Marketplace module roles handed out wholesale
A Marketplace module ships with its own module roles. Granting them all to end users hands out whatever that module can reach.
Roles that cancel each other out
Stack two module roles and the wider one wins. A restriction modelled in one place quietly disappears because another role grants the same entity.
User management rights outside administration
Rights to create and edit accounts on a role that is not an administrator, which turns any holder into an account factory.
Tenant admins with user management
In a multi-tenant app, user management on a tenant-level administrator is the shortest route across the tenant boundary.
Roles multiplied instead of modelled
Access differences solved by giving people several user roles, so nobody can say afterwards what any one person can actually reach.
What it lets someone do.
Every item below has been found in production applications. None of them requires a sophisticated attacker: they require somebody who reads the page source, edits a request or simply logs in.
How to keep it out.
One user role per user
Model the differences with permission entities, XPath constraints and microflow logic instead of stacking roles on one person.
User management through microflows
Keep user management rights off the user role itself and handle account administration in microflows with their own constraints.
Purpose-built module roles
Build a module role per user role rather than reusing defaults, and re-check the required roles every time a Marketplace module is updated.
What Omnext checks for you.
Omnext reads the full role model and reports every module role that reaches further than the user role it sits in, including the roles that arrive with Marketplace modules.
The framework is The S-Unit's.
The S-Unit Top 10 is the work of The S-Unit, the Mendix security specialists. They built it from more than ten years of offensive security work and hundreds of Mendix penetration tests, and they maintain the canonical version. Omnext automates the checks in the Security Analysis module; the framework itself is theirs, and this page explains it in our own words.
Which of the ten are you sure about?
Ten questions, about four minutes, results on screen. Or let the scan answer all ten with evidence from your own model.