The S-Unit

The S-Unit Top 10

The S-Unit Top 10, TSU-01 Insecure User roles

TSU-01: Insecure user roles

TSU-01 highlights the risks that arise when permissions in Mendix are set too broadly. When users are granted excessive rights, they may gain access to functions or data not intended for them, which can potentially lead to data leaks. A secure configuration starts with limiting permissions to what is strictly necessary, avoiding overlapping roles, and carefully assigning module roles. By consistently applying these principles, you maintain control over user access and significantly reduce the risk of misuse.

Excessive permissions? This is how vulnerabilities in User Roles arise.

Mendix uses Role Based Access Control (RBAC) to determine which actions a user is allowed to perform. Each user has one or more User Roles linked to specific module roles and, in some cases, supplemented with rights for user management. When these roles are misconfigured, users may gain more access than intended, leading to issues such as unauthorized data access or even data leaks.

TSU-01 vs TSU-02

TSU-01 and TSU-02 are often confused. Both deal with users having too much access, but understanding the difference helps you prevent risks more effectively.

TSU-01
  • In TSU 01, the access rule itself is correct, but the module role is assigned to the wrong User Role.
TSU-02
  • In TSU-02 , the access rule is incorrect for the module role, no matter which User Role it belongs to.

Put security before convenience: limit access in User Roles.

Limit user privileges to what’s strictly necessary. This helps you stay in control of your application and prevent TSU-01 vulnerabilities. Use the following best practices as your guide.

  • Do not assign User Management rights to User Roles. Instead, use microflows and XPath constraints to manage users securely.
  • Assign each user only one User Role. If flexible access is needed, extend the RBAC system with permission entities, XPath constraints, and microflow logic that continues to enforce security per role.
  • If creating specific module roles isn’t feasible (for example, when working with frequently updated Marketplace modules), carefully review which roles are truly necessary and whether they align with your application’s security requirements.
  • Create module roles that are specific to each User Role. Avoid default roles or assigning multiple module roles within a single module.

Vulnerabilities within TSU-01

Watch out for these common configuration mistakes to prevent users from gaining more access than intended.

  • Administrative module roles assigned to non-administrative users: this gives regular users access to functions or data intended only for administrators.
  • Sensitive Marketplace module roles assigned to non-administrative users: this can expose critical or external components of the application to unintended users.
  • Conflicting module roles: overlapping or contradictory roles may bypass intended security restrictions.
  • Conflicting user roles: when a user holds multiple roles with different privileges, it can lead to unexpected privilege escalation.
  • User management privileges assigned to non-administrative users: users may gain the ability to modify or delete other accounts, compromising application integrity.
  • User management privileges assigned to tenant-level administrators in multi-tenant environments: this may allow one tenant to access data or settings from another tenant.

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.