Space permissions and page restrictions are not the same thing

[#1]

Confluence has two separate permission systems, and almost every access-review mistake I see comes from treating them as one. Space permissions decide who can get into a space at all. Page restrictions decide who can reach an individual page. They are configured in different places, they behave differently, and changing one does nothing to the other.

This post is about where they meet, which is the part that catches people out.

The one rule that explains most of it

Restrictions subtract. They never add.

To view a page, a person needs space View permission and to not be excluded by a page restriction. Adding someone to a page's restriction list does not grant them access to a space they could not otherwise enter. If they lack space permission, they still see nothing, and no amount of editing the page restriction will change that.

This is why "I added Anna to the restriction and she still cannot see it" is such a common support question. Anna is not blocked by the page. She is blocked one layer up.

What each layer actually controls

Space permissions (Space settings, then Permissions) cover who can view the space, add and delete content, manage the space, and so on. They are granted to individual users, to groups, and to access classes such as all licensed users, anonymous access, and product admins.

Page restrictions (the padlock on a page, or the three dots menu) cover two operations only: who can view this page, and who can edit it. They are set per page and apply on top of whatever space permissions already allow.

The four states, and what each one means

Any given page sits in one of these. It is worth walking a few of your own pages through the grid, because the diagonal is where the surprises live.

Space open, page unrestricted	Everyone in the space can read and edit. Normal for most documentation.
Space open, page restricted	The usual way to hide something sensitive inside an otherwise open space. This is the case worth auditing most closely, because the page is the only thing standing between the content and everyone in the space.
Space restricted, page unrestricted	Everyone who can get into the space can read and edit the page. People often assume the space restriction is doing more work here than it is.
Space restricted, page restricted	Both layers apply. The audience is the intersection, not the union.

Three places the confusion causes real problems

1. Bulk space access does not touch page restrictions. Confluence Administration has a Bulk space access tool that adds or removes a user or group across many spaces at once. It is genuinely useful and it works well. It also does nothing whatsoever to page restrictions. Removing someone's space access does stop them reaching restricted pages, because of the rule above, but their name stays sitting on every restriction list they were ever added to. Reinstate their space access later, perhaps because they changed teams and came back, and all of that page-level access silently returns.

2. "The space is locked down" is not an answer to "who can edit this page". A restricted space with fifty people in it still means fifty potential editors of every unrestricted page inside it. If your sensitive material lives in a space that a whole department can enter, the space permission is not protecting it. The page restriction is, or nothing is.

3. Edit restrictions do not inherit, and space permissions cannot compensate. View restrictions cascade down the page tree. Edit restrictions do not. So a child page can inherit its parent's view restriction, look locked, and still be editable by everyone who can see it. No space-level setting fixes this, because the two layers do not talk to each other. I wrote that one up separately in how to audit who can view and edit every page.

Checking each layer

Space layer. Space settings, then Permissions, shows the full grant table for one space. For a site-wide view, Confluence Administration has Bulk space access, which will show you where a given user or group has space access. It answers "where can this person get in", which is the right question when someone leaves.

Page layer. Open a page, three dots, Restrict Permissions. It shows the view and edit lists and tells you whether restrictions are inherited from an ancestor, though not from which ancestor. To find that, walk up the tree from the space home until you hit the first ancestor carrying a view restriction.

Neither view aggregates. That is the honest limitation of both: Cloud has no report that puts space grants and page restrictions side by side, so the intersection has to be assembled by hand or with tooling.

An access review that covers both layers

1. Anonymous access. Check whether any space grants read to anonymous. This is the one that matters most and takes ten seconds to check.
2. Everyone-can-administer. A space where all licensed users hold space admin can have its permissions changed by anyone, including changing yours.
3. Space ownership. A space with exactly one named admin has a bus factor of one. A space with none has nobody who reviews it.
4. Restrictions naming departed people. Cross-check restriction lists against deactivated accounts. This is the layer bulk space access does not clean up.
5. View-restricted pages with no edit restriction. The inheritance gap. Highest value page-level check, and invisible unless you compare the two lists per page.
6. Guests and external collaborators. Check both layers, since a guest can hold space access, page-level access, or both.

If you migrated from Data Center

Worth calling out because it surprises people at the worst moment. On Server and Data Center you could answer most of these with a SQL query against the database. On Cloud that option is gone and there is no equivalent report, so teams that had a working access-review process before a migration often find they no longer do. The permissions themselves migrate. The ability to audit them in bulk does not.

Closing

If you take one thing from this: when you next hear "that space is locked down", ask which layer, and then ask what the other one says. The gap between those two answers is where the interesting findings are.

Disclosure on where I am coming from: I am the founder of Stackedboost, an Atlassian Marketplace Partner, so Confluence permissions are something I spend an unreasonable amount of time inside.

If you run access reviews across both layers and have found a cleaner way to reconcile them than assembling the table yourself, I would genuinely like to hear it. That reconciliation is still the part with no good answer.