ACR Rules

  1. Home
  2. Docs
  3. ACR Rules
  4. Security (28)
  5. Entity access rules should be using attributes/associations with at most read access in XPath constraints

Entity access rules should be using attributes/associations with at most read access in XPath constraints

Introduced in version 2.5 (released May 2021), extended in version 2.7 (release September 2021)

In an entity object, you can configure access rules for specific module roles. If the access rule uses an XPath constraint, the XPath should only refer to attributes and associations with read or none access. If the XPath uses attributes or associations with read, write access, it may cause a security breach. 

In the examples below, we have a Tenant entity and six entities with (non-)compliant XPaths that are associations of the Tenant entity.

Non-compliant examples

Case 1: EntityNOK has an attribute with read, write access rights.
The XPath constraint of EntityNOK refers to this attribute.

Case 2: One Tenant object is associated with multiple EntityNOK_2 objects. The Tenant object has one Read, Write attribute.
Via the XPath constraint of EntityNOK2, the user has access to the read, write attribute of Tenant.

Case 3: EntityNOK_3 has both an attribute and the association to the Tenant entity with read, write access.
The XPath constraint uses the association path to go to the current user.

Case 4: EntityNOK_4 has both an attribute and the association to the Tenant entity with read, write access. One Tenant object is associated with multiple EntityNOK_2 objects. The Tenant object has one Read, Write attribute. 
Via the XPath constraint, it uses the association, and it has access to the read, write attribute of the Tenant entity, resulting in two violations.

Case 5: One Tenant object is associated with one EntityNOT_5 object. Tenant has read, write access on its association with EntityNOK_5. EntityNOK_5 has read-only access on its association with Tenant.
EntityNOK_5 uses an XPath constraint over the Tenant association.
Even though the access rights over the association are read-only from EntityNOT_5, since the access rule for this association in the Tenant object is read, write, this XPath violates this security rule.

Compliant example

EntityOK only uses attributes and associations that have read or none access in its Xpath constraint.

How to solve a violation

Ensure that all the direct and indirect attributes and associations you use in an XPath have read-only access.