Advise customer on separating security and business entities by MarkvanMents · Pull Request #11824 · mendix/docs

MarkvanMents · 2026-08-27T13:30:14Z

No description provided.

knorrie · 2026-09-04T12:34:05Z

-* Constraints on widgets in pages should not be used as a measure of security, but can filter out irrelevant data for the context of the page
-* Keep your attributes editable within data views, because if an access rule prohibits write access, your client will display it as non-editable – this way you are aware of the (correct) working of an access rule
+* Do not make attributes determined by the system (like the status of an order) writable
+* If an anonymous user is allowed to create objects, constrain these objects to the owner (an anonymous user is a **System.User** object created on the fly)


Link to a place in the docs where it shows how to do xpath id = currentuser?

Done e6dcf89

knorrie · 2026-09-04T12:37:38Z

-* Keep your attributes editable within data views, because if an access rule prohibits write access, your client will display it as non-editable – this way you are aware of the (correct) working of an access rule
+* Do not make attributes determined by the system (like the status of an order) writable
+* If an anonymous user is allowed to create objects, constrain these objects to the owner (an anonymous user is a **System.User** object created on the fly)
+* Do not set a default rule for read-and-write access—this forces you to think about each attribute that is added to an entity


This is not a 'rule you set'. This is about the radio button "Default rights for new members" (o)None ( ) Read ( ) Read, Write, where None must be selected. This is also what is taught in class room training, security workshops and CTF stuff, to never use this.

Done e6dcf89

knorrie · 2026-09-04T13:00:00Z

+* Disable anonymous access if it has no function within the application
+    * Some applications have anonymous access enabled, solely to serve a custom login form—this can be replaced by modifying the default *login.html* within your theme (which will also help the user experience with an improved loading time)
+* Make roles managing other user roles as strict as possible (configured via **User management** within the user role options)
+* Only allow the role of the app's administrator user (default **MxAdmin**) to create the actual administrative accounts (or configure Single Sign On (SSO))


Best practice: Use this Administrator role only for local account management and/or SSO config, do not give it further access rights on your business process data. (This happens a lot where app developers mindlessly check everything readwrite for their business app data, even if there is no UI for it at all.)

Use a separate user role to organize 'god mode' access to business data if needed (fixing things 'in the backend').

Done e6dcf89

knorrie · 2026-09-04T13:04:56Z

+Which users and roles are defined within an application changes, depending on the function of the app. However, there are some key guidelines to keep in mind when validating the user security:

-You can take the following preventative measures:
+* Disable anonymous access if it has no function within the application


Link to other place where more best practices for Anonymous are mentioned?
https://docs.mendix.com/refguide/anonymous-users/

By the way, in there it should be mentioned more explicitly to best practice recommend to have a dedicated user role (preferably named "Anonymous") for it, and in modules have explicit Anonymous module roles, and not mixed with existing other module roles (for internal logged in user)

Done e6dcf89

knorrie · 2026-09-04T13:07:32Z

+When deployed to Mendix Cloud, the information about the administrator user name and role is taken into account when using the **Change admin password** button on the environment. After changing the settings in Studio Pro and redeploying the application, a successful admin password change will trigger the creation of a user in the app with the new name and role.

 {{% alert color="info" %}}
 At this point, the application does not automatically remove the user with the previous user name. Removing the old **MxAdmin** account has to be done manually.


It's only the old "MxAdmin account" if the previous name was MxAdmin, not if you change it from Banana to Apple later.

Changed e6dcf89

knorrie · 2026-09-04T13:15:32Z

 ```

-Because of this XPath constraint, access defined in the access rule is only applied to orders for which the customer is the current end-user.
+Applying this XPath constraint means the current end-user can only see orders for the customer associated with the current end-user.


Maybe?! change/improve wording because ambiguity: 'customer' can be used both as 'customer person' and 'customer company'. In the example here you constrain to the individual person.

A common real life case is of course that you can see orders placed by your customer company (also by other employees at your customer company). But we want to have a simple example here.

Another way to solve the confusion is to explicitly mention that the example we use is of the style of a webshop with individual visitors, not a business thing.

Tried to clarify e6dcf89

MarkvanMents

Thanks for the review @knorrie
I've responded to most of the comments in e6dcf89.

MarkvanMents · 2026-09-07T14:06:46Z

-* Constraints on widgets in pages should not be used as a measure of security, but can filter out irrelevant data for the context of the page
-* Keep your attributes editable within data views, because if an access rule prohibits write access, your client will display it as non-editable – this way you are aware of the (correct) working of an access rule
+* Do not make attributes determined by the system (like the status of an order) writable
+* If an anonymous user is allowed to create objects, constrain these objects to the owner (an anonymous user is a **System.User** object created on the fly)


Done e6dcf89

MarkvanMents · 2026-09-07T14:06:56Z

-* Keep your attributes editable within data views, because if an access rule prohibits write access, your client will display it as non-editable – this way you are aware of the (correct) working of an access rule
+* Do not make attributes determined by the system (like the status of an order) writable
+* If an anonymous user is allowed to create objects, constrain these objects to the owner (an anonymous user is a **System.User** object created on the fly)
+* Do not set a default rule for read-and-write access—this forces you to think about each attribute that is added to an entity


Done e6dcf89

MarkvanMents · 2026-09-07T14:07:09Z

+Which users and roles are defined within an application changes, depending on the function of the app. However, there are some key guidelines to keep in mind when validating the user security:

-You can take the following preventative measures:
+* Disable anonymous access if it has no function within the application


Done e6dcf89

MarkvanMents · 2026-09-07T14:07:18Z

+* Disable anonymous access if it has no function within the application
+    * Some applications have anonymous access enabled, solely to serve a custom login form—this can be replaced by modifying the default *login.html* within your theme (which will also help the user experience with an improved loading time)
+* Make roles managing other user roles as strict as possible (configured via **User management** within the user role options)
+* Only allow the role of the app's administrator user (default **MxAdmin**) to create the actual administrative accounts (or configure Single Sign On (SSO))


Done e6dcf89

MarkvanMents · 2026-09-07T14:07:32Z

+When deployed to Mendix Cloud, the information about the administrator user name and role is taken into account when using the **Change admin password** button on the environment. After changing the settings in Studio Pro and redeploying the application, a successful admin password change will trigger the creation of a user in the app with the new name and role.

 {{% alert color="info" %}}
 At this point, the application does not automatically remove the user with the previous user name. Removing the old **MxAdmin** account has to be done manually.


Changed e6dcf89

MarkvanMents · 2026-09-07T14:08:01Z

 ```

-Because of this XPath constraint, access defined in the access rule is only applied to orders for which the customer is the current end-user.
+Applying this XPath constraint means the current end-user can only see orders for the customer associated with the current end-user.


Tried to clarify e6dcf89

MarkvanMents added 5 commits August 27, 2026 13:43

Mark documentation to be updated with TO DO messages

1110900

Reorder the best practices so that more similar ones are together.

6488e69

Add section on separating security and business information.

a9656c9

Apply Claude review comments

c7565f9

Review against style guide.

a5f16b2

MarkvanMents added Needs R&D technical verification Internal WIP labels Aug 27, 2026

MarkvanMents self-assigned this Aug 27, 2026

knorrie reviewed Sep 1, 2026

View reviewed changes

Comment thread content/en/docs/howto/security/best-practices-security.md Outdated

MarkvanMents added 4 commits September 1, 2026 17:03

Change section title.

dd0a881

Apply Review comments

0a99572

Clarify how the administrator gets to manage users in a new app.

5ffa97f

Make better **Path to user.**. example

7f8e4e1

github-actions Bot reviewed Sep 4, 2026

View reviewed changes

Comment thread content/en/docs/refguide/modeling/security/app-security/administrator.md

knorrie reviewed Sep 4, 2026

View reviewed changes

Comment thread content/en/docs/refguide/modeling/security/app-security/administrator.md

knorrie reviewed Sep 4, 2026

View reviewed changes

Comment thread content/en/docs/howto/security/best-practices-security.md

knorrie reviewed Sep 4, 2026

View reviewed changes

MarkvanMents added 2 commits September 7, 2026 15:59

Respond to review

e6dcf89

Remove To Do items and record elsewhere

c577309

MarkvanMents commented Sep 7, 2026

View reviewed changes

Uh oh!

Conversation

MarkvanMents commented Aug 27, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MarkvanMents left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants