Confluence Page Restrictions: Space-Level Inheritance

Problem: Page viewable despite active restrictions

An administrator marks a Confluence page as restricted, yet a user with only space-level browse permission can still open it. The confusion stems from how page-level restrictions interact with space-level permissions, and without checking both layers, access decisions can be surprising.

What page restrictions enforce

Page restrictions let admins limit who can view or edit a specific page, independently of the space's default permissions. When active, a lock icon appears on the page header and a tooltip lists allowed users and groups. This feature protects sensitive content without altering overall space security.

Inheritance and override rules

Restrictions inherit the space-level permissions unless explicitly overridden. A space-level Browse grant to a group means every page is accessible to that group unless a page restriction explicitly denies them. Conversely, a page restriction can be made more permissive (adding allowed users) or more restrictive (adding denied users) compared to space defaults.

Verifying restrictions

Two reliable methods exist to see who can view or edit a page:

• UI method: Open the page, click the Restrictions button near the page title, and review the tooltip that shows allowed users and groups.
• REST API method: Call GET /rest/api/content/{id}/restriction with credentials appropriate for the instance. The response includes view.users, view.groups, edit.users, and edit.groups arrays.

Run the API command from a machine with network access to your Confluence instance. You need space admin or system admin rights to query another user's restrictions. After running the command, compare the listed groups with the UI tooltip; any extra entries indicate a space-level permission is broadening access.

Worked example: tightening access to a sensitive page

Scenario: A space named PROJECTS grants the group viewers browse rights at the space level. Page 12345 should be visible only to the editors group.

1. In Space Settings, confirm that viewers have Browse rights at the space level.
2. Open page 12345 and click Restrictions. Add editors to the View list and remove viewers from that list. The page header will show a lock icon.
3. Verify via the UI that viewers no longer appear under View.
4. Confirm with the API:

curl -u admin:password https://confluence.example.com/rest/api/content/12345/restriction

Typical response fields include view.users, view.groups, edit.users, and edit.groups. Compare the API output with the UI list; discrepancies suggest a misconfiguration or an overriding space permission.

Important: never claim this exact output was tested; the JSON structure reflects the Confluence API schema documented by Atlassian.

Trade-off and limitation

Page restrictions can be overridden by space-level permissions, which may cause unexpected access. A user with Browse space permission can still be blocked if a page restriction explicitly denies them, but if the space permission is broader than the page restriction, the user may gain access unintentionally. This dual-layer model adds complexity and requires verification after any permission change.

Actionable closing

To ensure page restrictions work as intended: open the target page and click Restrictions to view the current allow/deny list; confirm that space-level permissions do not grant broader access than intended; use the REST API command shown above (replace {id} with the page ID and supply admin credentials) to fetch the exact restriction JSON; compare the API output with the UI list; if changes are needed, edit the restrictions through the UI or update the JSON via the API (/rest/api/content/{id}/restriction) and re-verify; finally, test the final state by logging in as a user who should be blocked and confirming they cannot view the page.