Insecure microflows
Microflows are the back end. They run with elevated rights, they take input from whoever calls them, and the platform will not authorise on your behalf. A microflow that trusts its parameters, or that can be called directly when it was only ever meant to be a step in a larger flow, is a straight line from the browser to your data.
How this shows up in a Mendix application.
No authorisation on delete and save
The flow that removes or commits an object never checks whether this user is allowed to touch this object.
Parameters taken on trust
Object and non-object parameters alike arrive from the client and are used without validation, as is data retrieved from the database afterwards.
Validation only in a nanoflow
The check runs in the browser, so nothing enforces it on the server and the microflow behind it accepts anything.
Data left in non-persistent entities
Temporary objects created along the way are visible to the user, including the ones a sub-microflow made and never cleaned up.
Sub-microflows callable directly
A flow meant to be one step of a sequence is exposed on its own, so the steps before it, including the checks, are skipped.
Module roles drawn too wide
The microflow is allowed for roles that should never reach it, usually because one role was easier than modelling two.
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.
Name flows by who may call them
A naming convention that says whether a flow is callable from the UI and by which roles makes a wrong setting visible during review.
Authorise and validate first
Treat every parameter, writable attribute and retrieved object as untrusted, and check before the sensitive action rather than after.
Add a step the user cannot repeat
Set a read-only status after validation and constrain on it, so passing the check is something only the server can do.
What Omnext checks for you.
Omnext traces which microflows are reachable from the client, which run without an authorisation check, and where non-persistent objects carrying sensitive data outlive the flow that made them.
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.