Confluence Page Restrictions: How They Interact with Space Permissions (and Where They Leak)

Page restrictions in Confluence are an exception layer, not a security boundary. A restriction can only narrow the audience a space's permissions already allow — it can never grant access to someone the space itself excludes. Keeping that one rule in mind prevents most of the confusing "why can't they see the page" tickets.

The useful answer first

Use the Restrict dialog (the lock icon, or ⋯ → Restrictions depending on version) when a page or a small subtree needs a smaller audience than the rest of the space. Do not use it as your primary access model: restrictions are per-page, inherited down the page tree, and invisible in most admin overviews, so heavy reliance on them becomes unauditable quickly. If more than a handful of pages in a space need a different audience, that content usually belongs in its own space.

How the mechanism actually works

Confluence evaluates access in two layers:

1. Space permissions. The space grants View, Add, Edit, Delete, Export, and admin rights to users and groups. This is the ceiling.
2. Page restrictions. A page can carry View restrictions and/or Edit restrictions listing specific users or groups. If a View restriction exists, only listed people (who also pass layer 1) can see the page and all its descendants. Edit restrictions work the same way for editing.

Two consequences follow directly:

• Restricting a page to team-leads does nothing for a team lead who lacks View permission on the space. The page will appear inaccessible even to the people you listed. Fix the space permission, not the restriction.
• View restrictions cascade silently. Restrict one parent page and every child — including pages other people create there later — inherits the restriction. This is a feature for confidentiality and a trap for collaboration.

A worked configuration

Scenario: an Engineering space is viewable by all staff, but one page tree, "Compensation review", must be visible only to the eng-managers group while remaining editable by hr-partners.

1. In Space Settings → Permissions, confirm both eng-managers and hr-partners have View on the space (individually or via a broader group like all-staff).
2. Create a single parent page "Compensation review". Put everything sensitive under it, never as siblings.
3. Open the parent page → Restrictions → set View to eng-managers and hr-partners; set Edit to hr-partners only.
4. Verify: log in (or use a test account) as a manager — the page and children are visible and read-only. As a regular staff member, the page should not appear in search, the page tree, or recently-viewed lists.

That last check matters: Confluence filters restricted pages out of search results and macros like Page Tree and Recently Updated for unauthorized users, so a quick search from a non-privileged account is a realistic end-to-end test.

Where restrictions leak or surprise you

• Exports. Anyone who can view a page can typically export it to PDF or Word and share the file freely — the restriction does not travel with the export. Treat restrictions as controlling in-app access, not information flow. If export rights matter, review the space-level Export permission.
• Attachments and embedded content. Attachments inherit the page's restrictions, but a file attached to an unrestricted page and merely embedded on a restricted one stays exposed. Upload sensitive files on the restricted page itself.
• Edit vs. Add Children. An Edit restriction stops modification of that page but does not by itself stop someone with space-level Add rights from creating children under it (children then inherit the View restriction, which can produce pages the creator can't see). Plan the tree so restricted sections have a single, controlled parent.
• Orphaned audiences. Restrictions reference users and groups by identity; when a group is renamed or a user leaves, nobody gets a warning. Schedule a periodic audit.

Auditing what you have

There is no single built-in report of all restricted pages in a space. On Confluence Data Center/Server, administrators can query the database — restrictions live in the CONTENT_PERM table joined to CONTENT — for example:

SELECT c.title, cp.perm_type, cp.groupname, cp.username
FROM content_perm cp
JOIN content c ON c.contentid = cp.content_id
WHERE c.spaceid = 12345
  AND c.prevver IS NULL;

Run this read-only query against the Confluence database as a DBA or admin with DB access; 12345 is the space's ID (visible in Space Settings → Details). Never write to this table directly — change restrictions through the UI or REST API (GET /rest/api/content/{id}/restriction works on both Cloud and Data Center and is the safer audit path for Cloud).

Limits and version notes

Behavior described here applies to current Confluence Cloud and Data Center 7.x/8.x; exact menu labels differ slightly between them. After bulk permission changes on self-managed instances, allow time for re-indexing before trusting search-based verification. If you depend on restrictions for regulated data, confirm export and public-link settings in your own instance — defaults have changed across versions, so verify rather than assume.