Security Recommendations

Last modified: October 8, 2026

Introduction

This document outlines the security best practices provided by Best Practice Recommender in Studio Pro.

Anonymous User Best Practices

Anonymous users can access an app without signing in, which means that every access right held by the anonymous user role is available to anyone who can reach the URL of the app. You should only add anonymous users to your app where you have data which you want anyone to be able to access. One example is allowing users to browse the stock of a webshop.

Because of the risks of allowing anonymous users, Mendix has a number of best practices around them.

This section outlines security issues and Mendix best practices for anonymous users.

Best Practice Recommender checks the best practices in this section when both of the following conditions are met:

  • The security level of the app is Prototype/demo or Production.
  • Allow anonymous users is set to Yes in the Anonymous users tab of App Security.

Disable Anonymous Users [MXS003]

Anonymous users are enabled in App Security.

Enabling anonymous users gives a level of access to anyone who can reach the URL of the app, without signing in. If this access is not controlled, this may result in unauthorized access to the app and its data. Additionally, because anonymous users are given new identifiers for each session with the app, you cannot attribute actions to an identifiable user

Steps to Fix

If you do not need anonymous users, set Allow anonymous users to No in the Anonymous users tab of App Security.

This action can be performed automatically. In the recommendation, click Fix to disable anonymous users. See Auto-Fixing the Anti-Pattern for more information.

Avoid Granting Anonymous Users Access to Sensitive Entities [MXS004]

The anonymous user role has read or write access to an entity outside the System module that inherits from a System module entity.

System entities can carry identity data such as user names, email addresses, role assignments, or arbitrary file content. This is normally constrained using an XPath constraint to the current user. However, the same anonymous user will have a different anonymous account for different sessions. This means that even a constrained access rule risks exposing or substituting the wrong record across sessions, so access should be denied outright rather than constrained.

Steps to Fix

To fix the issue, remove the access rule that grants the anonymous user role access to this entity.

Do Not Use the Administrator User Role for Anonymous Access [MXS005]

The user role configured for anonymous access is the same as the user role configured for the administrator.

Anonymous access and administrator access resolving to the same user role grants the full access of an administrator to anyone who can reach the URL of the app, without them needing to sign in. This may result in unauthorized access to the app and its data.

This is unwanted and almost certainly a configuration error.

Steps to Fix

To fix the issue, assign anonymous access to a dedicated user role that is not the administrator user role.

This recommendation can be fixed automatically. In the recommendation, click Fix to create a dedicated Anonymous user role and assign anonymous access to it.

Avoid Granting Anonymous Users Write Access to Persistable Entities [MXS006]

The anonymous user role has create, update, or delete access to an attribute or association of a persistable entity.

Anonymous sessions have no durable, verifiable identity behind them. Granting them any write capability lets anyone modify persistable data with no accountability trail.

Steps to Fix

To fix the issue, remove the create, update, and delete access that the access rule grants the anonymous user role.

If anonymous users need to submit one-off input, route it through a non-persistable entity or page variables and validate it server-side, instead of granting direct write access.

Do Not Let Anonymous Users Manage User Roles [MXS007]

The user role configured for anonymous access has one or more entries selected under user management.

User management lets a user role create and manage users for the user roles that it manages. When the anonymous user role manages one or more user roles, an unauthenticated visitor can create accounts for those roles and escalate privileges for themselves or others.

Steps to Fix

To fix the issue, remove all entries under user management for the user role that is configured for anonymous access.

This recommendation can be fixed automatically. In the recommendation, click Fix to remove all entries under user management for that user role.

Do Not Share Module Roles Between Anonymous and Other User Roles [MXS008]

A module role that does not come from the System module is mapped to the anonymous user role and to one or more other user roles.

Reusing access rights for anonymous users that are also used for signed-in users is a high risk and often leads to misconfigured security. Every access rule, page, and microflow that is opened up for the shared module role is opened up for unauthenticated visitors. As a result, if you change the access for the module role to give more access to signed-in users at a later stage, this will also grant it to anonymous users without anyone revisiting the anonymous access rules.

Steps to Fix

To fix the issue, do the following:

  1. Remove the mapping, so that the module role is no longer mapped to the anonymous user role.
  2. Map the anonymous user role to module roles that are used exclusively for anonymous access. This way, its access rights can be reviewed and changed independently of those of other user roles.

This recommendation can be fixed automatically. In the recommendation, click Fix to remove the shared module roles from the anonymous user role.

Do Not Map Administration Module Roles to the Anonymous User Role [MXS009]

The anonymous user role is mapped to a module role of the Administration module from the Marketplace, such as Administration.User or Administration.Administrator.

The module roles of the Administration module grant access to sensitive entities, such as Account, which holds the credentials and role assignments of the users of the app. The Administration.Administrator module role additionally grants the full administrative capability of managing accounts and their user roles. Granting any of this to the anonymous user role exposes these entities to anyone who can reach the URL of the app, without signing in.

Steps to Fix

To fix the issue, remove the mappings to Administration module roles from the anonymous user role.

This recommendation can be fixed automatically. In the recommendation, click Fix to remove the Administration module roles from the anonymous user role.

Constrain the Read Access of Anonymous Users [MXS010]

The anonymous user role has read access to a persistable entity through an access rule that has no XPath constraint.

Without an XPath constraint, the access rule returns every object of the entity to every anonymous session. Data that was only ever meant to be visible to the visitor who submitted it, such as problem reports or form submissions, then becomes readable by all unauthenticated visitors. This is the most common way in which anonymous access leaks the data of unrelated users.

Adding an XPath constraint for an anonymous user may not give you the results you expect because the same anonymous user can have a different [%CurrentUser%] assigned if they start a new session. Mendix recommends changing your app design (for example by making users sign in or sending confirmation of information on a form via email or some other persistable method outside the app) if you find yourself giving access for an anonymous user to a persistable entity with information which needs to be limited depending on who the user is.

Steps to Fix

To fix the issue, add an XPath constraint to the access rule, so that it only returns the objects that the current anonymous session is allowed to see, for example by constraining on the owner of the object. If the objects cannot be narrowed down to the current session, remove the read access instead.

Read More