The S-Unit Top 10

TSU-03: Insecure Microflows

TSU-03 focuses on the insecure configuration or implementation of microflows , a crucial part of Mendix security. By designing microflows carefully, managing authorizations strictly, and consistently building in validations, you prevent sensitive logic or data from being unintentionally exposed.

Incorrect microflow settings can undermine security.

Microflows form the core of backend validations and sensitive functions within a Mendix app. They often run with elevated privileges and frequently process user input.

By default, Mendix blocks access to microflows. Developers decide which module roles are allowed to execute them. An overly broad configuration or insufficient validation can lead to unauthorized access, data manipulation, or even circumvention of security mechanisms.

Reduce risks by designing your microflows smartly and securely.

To prevent TSU-03 vulnerabilities, consider for each microflow who is allowed to call it and what validations are required. Follow these best practices.

Use a clear naming convention that shows whether a microflow can be called from the UI and by which module roles.
Identify actions within the microflow that end users normally cannot perform (for example, backend-only operations) and mark these as sensitive.
If the microflow doesn’t perform sensitive actions, convert it to a nanoflow.
Track all user-provided data in the microflow: including parameters, writable attributes, and retrieved entities and treat them as input that must be validated.
Ensure that user-exposed microflows perform authorization and input validation before executing sensitive actions.
Do not assume that only the “Commit” action saves data. Any attribute change may be stored, with or without an explicit commit. Apply the same security checks in both cases.
Avoid “validate-then-commit” microflows that rely solely on client-side validation. These can be bypassed. Add a backend-only step the user cannot perform, such as:

Changing a read-only attribute after validation (e.g., Status = Approved), combined with a status-based XPath constraint.
Creating a read-only persistent object after validating user input.

Assume that all entities created or modified in a microflow can be exposed to the user, including non-persistent entities and uncommitted changes.

Delete temporary objects once they’re no longer needed, especially in sub-microflows.

Vulnerabilities within TSU-03

The following vulnerabilities are common in insecurely configured microflows and illustrate where things often go wrong in practice.

Missing authorization checks in delete microflows: users can remove records without proper rights.
Missing authorization in data submission microflows: unauthorized data can be added or altered.
No validation of object parameters: invalid or unauthorized objects may be processed.
No validation of non-object parameters (such as strings or integers): increases the risk of injection or logic manipulation.
No validation after database retrieval: untrusted data might flow into critical processes.
Validation only in nanoflows: without matching backend checks, these can be easily bypassed.
Data validation bypass through uncommitted changes: users may view or alter data before it’s validated.
Exposure of sensitive data via temporary non-persistent entities: confidential information may become visible.
Security bypass via direct access to sub-microflows: unprotected subflows can be called directly.
Security bypass via direct access to administrative microflows : grants backend control to unauthorized users.

Integrate The S-Unit Top 10 into your CI/CD pipeline.

Want to know how your Mendix application scores on The S-Unit Top 10? In collaboration with Omnext, we’ve developed a Mendix-specific SAST solution that continuously and automatically scans for vulnerabilities. By integrating The S-Unit Top 10 into the CI/CD pipeline, risks are detected early and made immediately visible. For questions, feel free to contact us.