Using Confluence Page Restrictions for Granular Access Control

The Problem: Too Much or Too Little Access

In a shared space, a draft page may contain unfinished specifications that should only be visible to a small review team, while the rest of the space stays open for everyone. Granting edit rights to the whole space would expose the draft, and creating a separate space duplicates navigation.

How Confluence Page Restrictions Work

Confluence evaluates permissions in this order: first space‑level permissions, then any page‑level restrictions stored as an access control list on the page. A denial at the space level cannot be overridden by granting access at the page level. By default, a page’s restrictions flow down to its children, but a child can break inheritance and define its own list.

Worked Example: Limit a Draft Page to a Review Team

1. Navigate to the page you want to restrict. You need the Edit permission on that page (or be a space administrator).
2. Click the … menu in the top‑right corner and choose Restrictions.
3. In the Restrictions dialog, select View restriction (or Edit restriction if you also want to limit who can change the page).
4. Start typing the name of the group or user that should see the page, pick it from the list, and click Add. The dialog shows the entry with a lock icon.
5. Press Save. The page now displays a small lock icon next to its title, indicating that restrictions are in place.
6. To verify, log in as a user who is not in the allowed group. The page will not appear in the space hierarchy or search results, and attempting to open the URL directly shows a “You do not have permission to view this page” message.
7. For an API check, run a GET request (replace {pageId} with the page’s internal ID):

   GET /wiki/rest/api/content/{pageId}?expand=metadata.restrictions

   The response includes a metadata.restrictions object listing the user or group with the operation view (or edit). You need permission to call the API; a space admin or a user with View on the page suffices.

Trade‑offs and Limitations

• Each restricted page stores its own ACL; applying many individual restrictions increases administrative overhead and makes permission auditing harder, especially in deep hierarchies.
• Restrictions do not prevent indexing of content that is exposed through macros or attachments; administrators should still review search results for accidental leaks.
• Because a denial at the space level cannot be overridden, you must ensure the space itself grants at least View to the intended audience before adding more restrictive page rules.

Closing: Keep Your Permission Model Manageable

Use page restrictions when you need a one‑off exception to the space‑wide policy, such as a draft, a legal review, or a private meeting note. Document the rationale in a comment or a dedicated “Permissions” page, and periodically review the Restrictions report (Space tools → Content Tools → Restrictions) to spot stale rules. When the exception is no longer needed, return to the same Restrictions dialog and remove the entry—this rolls back the change without affecting other pages.