Bug Description
When a Confluence page has no explicit page-level restrictions set ("No restrictions"), but inherits view restrictions from a parent page, the connector indexes the document with an incorrect or overly broad _allow_access_control value (eq. space permissions). The inherited ACL from the parent page hierarchy is not resolved and applied to the child page document.
This is a Document Level Security gap: users who should not have access to a restricted child page may be able to retrieve it via Elasticsearch queries, because the indexed ACL does not reflect the effective (inherited) permission.
To Reproduce
Steps to reproduce the behavior:
-
In Confluence, create a parent page and restrict it to a specific set of groups/users ("Viewing and editing restricted").
Example — Parent page: "Parent Page" (ID: )
Restrictions: group-admin, group-power-user, group-standard-user, user:[user@example.com]. (mailto:user@example.com)
Everyone else: Has no access
-
Create a child page under that parent and leave it at the default "No restrictions" page-level setting.
Confluence UI confirms "There are inherited view restrictions" from the parent page.
-
Trigger a full sync of the Confluence Connector.
-
Query the indexed document for the child page in Elasticsearch and inspect the _allow_access_control field.
The _allow_access_control field of the child page document reflects space-level or license-level group membership instead of the effective inherited restrictions. For example, it includes a broader group such as "group:group-all-licensed-users" which should NOT have access to this page hierarchy.
Observation from Elasticsearch:
- Parent page (ID: ) — _allow_access_control correctly reflects the 4 restricted principals.
- Child page with "No restrictions" (page-level) — _allow_access_control does NOT reflect the inherited restrictions; instead it contains a broader permission set including groups that are explicitly excluded from the parent page.
Expected behavior
The _allow_access_control field of the child page document should contain the resolved effective permissions — i.e., the inherited restrictions from the parent page:
["group:group-admin", "group:group-power-user", "group:group-standard-user", "user:[user@example.com](mailto:user@example.com)"]
Bug Description
When a Confluence page has no explicit page-level restrictions set ("No restrictions"), but inherits view restrictions from a parent page, the connector indexes the document with an incorrect or overly broad _allow_access_control value (eq. space permissions). The inherited ACL from the parent page hierarchy is not resolved and applied to the child page document.
This is a Document Level Security gap: users who should not have access to a restricted child page may be able to retrieve it via Elasticsearch queries, because the indexed ACL does not reflect the effective (inherited) permission.
To Reproduce
Steps to reproduce the behavior:
In Confluence, create a parent page and restrict it to a specific set of groups/users ("Viewing and editing restricted").
Example — Parent page: "Parent Page" (ID: )
Restrictions: group-admin, group-power-user, group-standard-user, user:[user@example.com]. (mailto:user@example.com)
Everyone else: Has no access
Create a child page under that parent and leave it at the default "No restrictions" page-level setting.
Confluence UI confirms "There are inherited view restrictions" from the parent page.
Trigger a full sync of the Confluence Connector.
Query the indexed document for the child page in Elasticsearch and inspect the _allow_access_control field.
The _allow_access_control field of the child page document reflects space-level or license-level group membership instead of the effective inherited restrictions. For example, it includes a broader group such as "group:group-all-licensed-users" which should NOT have access to this page hierarchy.
Observation from Elasticsearch:
Expected behavior
The _allow_access_control field of the child page document should contain the resolved effective permissions — i.e., the inherited restrictions from the parent page: