Add documentation for the new Best Practice Recommender security rules

content/en/docs/refguide/mendix-ai-assistance/best-practice-recommender/performance-best-practices.md

@@ -1,18 +1,14 @@
 ---
-title: "Recommendations from Best Practice Recommender"
+title: "Performance Recommendations"
 url: /refguide/performance-best-practices/
-description: "Describes Mendix best practices from Best Practice Recommender."
+description: "Describes the performance best practices from Best Practice Recommender."
 #If moving or renaming this doc file, implement a temporary redirect and let the respective team know they should update the URL in the product. See Mapping to Products for more details.
 #The anchors <mxp001-mxpnnn> below are all mapped, so they should not be removed or changed.
 ---
 
 ## Introduction
 
-This document outlines all the best practices provided by [Best Practice Recommender](/refguide/best-practice-recommender/) in Studio Pro.
-
-## Performance Best Practices {#performance-best-practices}
-
-This section outlines performance issues and Mendix best practices for optimizing an app performance. 
+This document outlines the performance best practices provided by [Best Practice Recommender](/refguide/best-practice-recommender/) in Studio Pro. It describes potential performance issues and Mendix best practices for optimizing an app performance. 
 
 ### Calculated Attributes Best Practices [MXP001][MXP002] {#mxp001}
 
@@ -255,3 +251,9 @@ To fix the issue, do the following:
 {{% alert color="info" %}}
 This optimization may not be very beneficial for data types like Boolean and enumerations due to a limited number of possible values of these types. It is not recommended to add indexes for such types.
 {{% /alert %}}
+
+## Read More
+
+* [Best Practice Recommender](/refguide/best-practice-recommender/)
+* [Security Recommendations](/refguide/security-best-practices/)
+* [Mendix Best Practices for Development](/refguide/dev-best-practices/)

content/en/docs/refguide/mendix-ai-assistance/best-practice-recommender/security-best-practices.md

@@ -0,0 +1,143 @@
+---
+title: "Security Recommendations"
+url: /refguide/security-best-practices/
+description: "Describes the security best practices from Best Practice Recommender, including the best practices for anonymous users."
+#If moving or renaming this doc file, implement a temporary redirect and let the respective team know they should update the URL in the product. See Mapping to Products for more details.
+#The anchors <mxs001-mxsnnn> below are all mapped, so they should not be removed or changed.
+---
+
+## Introduction
+
+This document outlines the security best practices provided by [Best Practice Recommender](/refguide/best-practice-recommender/) in Studio Pro.
+
+## Anonymous User Best Practices {#anonymous-users}
+
+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](/refguide/anonymous-users/). 
+
+Best Practice Recommender checks the best practices in this section when both of the following conditions are met:
+
+* The [security level](/refguide/app-security/#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] {#mxs003}
+
+Anonymous users are enabled in [App Security](/refguide/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](/refguide/best-practice-recommender/#auto-fixing) for more information.
+
+{{% alert color="info" %}}
+If anonymous access is part of the design of your app, you can select **Suppress this recommendation** from the **Best Practice Recommender** pane and use the other best practices in this section to limit what anonymous users can reach.
+{{% /alert %}}
+
+### Avoid Granting Anonymous Users Access to Sensitive Entities [MXS004] {#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](/refguide/xpath-constraints/) 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](/refguide/access-rules/) that grants the anonymous user role access to this entity.
+
+### Do Not Use the Administrator User Role for Anonymous Access [MXS005] {#mxs005}
+
+The user role configured for anonymous access is the same as the user role configured for the [administrator](/refguide/app-security/#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](/refguide/user-roles/) 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.
+
+{{% alert color="info" %}}
+The automatic fix is not applied when a user role named **Anonymous** already exists. In that case, you must assign anonymous access to a user role that is not the administrator user role yourself. Mendix recommends that you use the **Anonymous** user role for this to make the purpose of the user role clear.
+{{% /alert %}}
+
+### Avoid Granting Anonymous Users Write Access to Persistable Entities [MXS006] {#mxs006}
+
+The anonymous user role has create, update, or delete access to an attribute or association of a [persistable entity](/refguide/persistability/).
+
+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](/refguide/access-rules/) 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] {#mxs007}
+
+The user role configured for anonymous access has one or more entries selected under [user management](/refguide/user-roles/#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] {#mxs008}
+
+A [module role](/refguide/module-security/) 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] {#mxs009}
+
+The anonymous user role is mapped to a module role of the [Administration](/appstore/modules/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] {#mxs010}
+
+The anonymous user role has read access to a [persistable entity](/refguide/persistability/) through an [access rule](/refguide/access-rules/) that has no [XPath constraint](/refguide/xpath-constraints/).
+
+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%]`](/refguide/xpath-keywords-and-system-variables/#system-variables) 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.
+
+{{% alert color="info" %}}
+This best practice is not reported for an access rule that also grants access to other user roles, because an XPath constraint applies to every module role of the access rule. Such an access rule is reported under [Do Not Share Module Roles Between Anonymous and Other User Roles](#mxs008) instead.
+{{% /alert %}}
+
+## Read More
+
+* [Best Practice Recommender](/refguide/best-practice-recommender/)
+* [Performance Recommendations](/refguide/performance-best-practices/)
+* [Anonymous Users](/refguide/anonymous-users/)
+* [App Security](/refguide/app-security/)
+* [Mendix Best Practices for Development](/refguide/dev-best-practices/)