How to see who can view and edit every Confluence page

Somebody has asked you, probably for an access review, and there is no screen that answers it. Here is the route that does, and the rule that makes the answer surprising.

What Confluence gives you, and where it stops

Tool	Answers	Does not answer
Space permissions screen	Who has access to the space	Anything about individual pages
Inspect permissions (General Configuration)	Space-level permissions, exportable	Page restrictions
Single-user permission inspector	“What can Anna see?”, one person at a time	“Who can see this page?”, across a space
Restrictions dialog on a page	That page	The other four hundred

On Server and Data Center you could query the database. On Cloud that door is closed, so the REST API is the route.

The rule that makes this worth doing

View restrictions inherit down the page tree. Edit restrictions do not.

So a page whose parent is edit-restricted to three people is, unless somebody restricted it separately, editable by everyone the space allows — while looking locked, because it sits under a padlock in the tree. This is documented behaviour rather than a bug: CONFCLOUD-5095, open since 2006.

It is also the finding nobody catches by clicking, because clicking the parent shows you the parent's restrictions and everything looks right. If you only check one thing after reading this page, check the children of your locked pages.

The free route, in full

Three calls, in a loop. Everything else is formatting.

List the pages in the space. GET /wiki/api/v2/spaces/{spaceId}/pages?limit=250, following the _links.next cursor until it stops. Do not assume one page of results; the space that matters is always the big one.
Read each page's restrictions. GET /wiki/rest/api/content/{id}/restriction returns the read and update operations with the users and groups named on each.
Expand every group to its members. GET /wiki/rest/api/group/{groupId}/membersByGroupId, paginated. “The legal group can edit this” is not an answer an auditor accepts; a list of names is.

Four things that will bite you, in the order they usually do:

The API only returns restrictions the calling account can see. Run it as an administrator or the report is quietly incomplete — which is worse than no report, because it looks like one.
Rate limits. One call per page plus one per group adds up fast. Back off on 429 and resume rather than restarting.
A page with no restrictions returns empty lists, not an error. Empty means “inherits whatever the space allows”, which is usually the interesting case rather than the boring one.
Deactivated accounts stay in restrictions. They are not removed when somebody leaves, so a grant naming a departed colleague survives indefinitely.

What the output should contain

For an access review, the deliverable is a table with one row per page: page title, its path, who can view, who can edit, and — the part that makes it evidence rather than a screenshot — the exact time the permissions were read. Permissions change. A report without a timestamp cannot be compared against the next one, which is the whole point of doing it every quarter.

One detail worth copying if you write this yourself: a page title beginning with =, +, - or @ is interpreted as a formula when the CSV is opened in a spreadsheet. Prefix such cells so they stay text. Nobody thinks of this until a page called =Q3 budget exists.

Where this comes from

We build Page Restrictions Auditor for Confluence, which does the walk described above and formats the result. The REST route is free and real, and for a one-off audit of a small space it is genuinely the cheaper answer.

Something here wrong or out of date? [email protected]. Written reply, one business day, and corrections go up with the date on them.