Add documentation for the new Best Practice Recommender security rules - #11851
Add documentation for the new Best Practice Recommender security rules#11851joerih wants to merge 3 commits into
Conversation
Make this a new page next to the already existing page about performance recommendations, and update the latter a bit to adapt it to this new structure.
|
This is the documentation of a new feature that will be released in version 11.15.0. |
| ### 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. | ||
|
|
||
| #### 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 %}} |
There was a problem hiding this comment.
Why do we recommend this - we say earlier on that putting an XPath constraint for an anonymous user is pointless as they will don't keep their user ID across sessions? But we now say it is a good idea.
There was a problem hiding this comment.
I agree, I'm not sure today what to say on this, today. If an anonymous session does not have any identity, then it makes no sense doing something so that they later can find back their own persisted data... Indeed.
There was a problem hiding this comment.
Yes, good question, this isn't explained very well. I've discussed it briefly with Jonathan, and the main purpose of this rule for constraining read access is to make sure the user at least thought about limiting access (because you can still write an XPath filter that does not look at the anonymous user id, but that restricts access in some other way).
There was a problem hiding this comment.
I've tried to explain the contradiction by adding something in ec38d82
3 participants
Make this a new page next to the already existing page about performance recommendations, and update the latter a bit to adapt it to this new structure.