apply suggestions from review

Author: renetapopova

modules/ROOT/pages/authentication-authorization/limitations.adoc

@@ -14,7 +14,8 @@ CREATE ROLE unrestricted;
 [[access-control-limitations]]
 = Limitations
 
-Using Neo4j's role-based access control imposes some limitations and implications that users should be aware of, such as:
+It is very important to apply the principle of least privilege when defining user roles and privileges.
+Further to that, Neo4j's role-based access control has some limitations and implications that users should be aware of, such as:
 
 * Impact on query results regardless of whether indexes are used.
 * Impact on query results when nodes have multiple labels.
@@ -190,22 +191,22 @@ In this case, the query will return zero results rather than simply returning th
 
 A `DENY` rule fails open when its criteria is not met, so Neo4j does not apply the restriction and it grants access by default if a broader `GRANT` exists.
 This can lead to unintended data exposure if the `DENY` rule is not carefully crafted.
+To avoid this, you can apply the principle of least privilege and allow access only to the specific data that the user should see.
 
 For example, consider the following scenarios:
 
 .Example of an un-met `DENY` failing open with property-based RBAC
 ====
-You grant a user access to a property, but then try to restrict it with a `DENY` rule that does not match the data.
-If the `DENY` rule does not match any data, it does not apply, and the user can still access the property.
-
+You grant a user access to a property and try to restrict it with a `DENY` rule.
+However, if the `DENY` rule does not match any data, for example, if the property is null or misspelled, the `DENY` rule will not apply, and the user can still access the property.
 [source, cypher]
 ----
 GRANT READ {salary} ON GRAPH * NODES Employee TO myRole
 DENY READ {salary} ON GRAPH * FOR (e:Employee) WHERE e.position = 'CEO' TO myRole
 ----
 In this case, if the `e.position` property is null or misspelled, the `DENY` rule will not apply, and `myRole` will see the `salary` property.
 
-A better way is to use a `GRANT` rule that only allows access to the `salary` property for employees whose position is not 'CEO'.
+A better way is to apply the principle of least privilege and only grant access to the `salary` property for employees whose position is not 'CEO'.
 [source, cypher]
 ----
 GRANT READ {salary} ON GRAPH * FOR (e:Employee) WHERE e.position <> 'CEO' TO myRole
@@ -244,7 +245,8 @@ Then, you try to restrict it with a `DENY` rule to prevent access to the `salary
 DENY READ {salary} ON GRAPH * NODES Management TO myRole;
 ----
 In this case, if the `Management` label is not present on a node that has the `salary` property, the `DENY` rule will not apply, and `myRole` will still see the `salary` property on that node.
-A better way is to use a `GRANT` rule to only allow access to the `salary` property for nodes that have a specific label, such as `IndividualContributor`:
+
+A better way is to apply the principle of least privilege and only grant access to the `salary` property for nodes that have a specific label, such as `IndividualContributor`:
 [source, cypher]
 ----
 GRANT READ {salary} ON GRAPH * NODES IndividualContributor TO myRole;