How to see every restricted page in Confluence Cloud, and who can read it

[#1]

Sooner or later a security review asks: which pages in this Confluence site are restricted, and who exactly can read them? Confluence has no screen that answers it. Restrictions are set one page at a time, by almost anyone, and nothing rolls them up. This post explains why the gap exists, how far the native tooling gets you, and where it runs out.

🔒 Why restriction visibility goes blind at scale

Page restrictions are powerful precisely because they are decentralized: any editor can lock a page to a handful of people without asking an admin. That convenience is the problem at audit time. Each restriction lives on its own page with no site-wide inventory. Restrictions rot quietly, still naming accounts deactivated a year ago, and nobody re-opens the page to notice. And read restrictions cascade to child pages, so a page can be effectively gated by an ancestor without carrying a restriction of its own.

A site-wide view is a long-running ask on the Confluence Cloud issue tracker: CONFCLOUD-74405 ("List which spaces and (restricted) pages a group can access") sits in gathering interest with about 122 votes as of this writing, and sibling tickets asking for the same restricted-pages list across a space or site have collected votes for years alongside it.

🧰 What you can do with native tooling

The native surface answers one page or one person at a time, and the REST API can be scripted into more:

• The per-page restrictions dialog. The lock control on any page shows exactly who holds view and edit there. Perfect for one page, useless for "show me all of them".
• Space permissions review. Space settings show who can enter the space at all, which frames what a page restriction can actually expose, but says nothing about which pages inside are restricted.
• Script the inventory. Enumerate every current page (`GET /wiki/api/v2/pages?status=current`, cursor-paged), then pull each page's restrictions from the v1 endpoint (`GET /wiki/rest/api/content/{id}/restriction?expand=restrictions.user,restrictions.group`; v2 has no restrictions read endpoint yet). To find restrictions naming deactivated accounts, batch the collected account ids through `POST /wiki/api/v2/users-bulk` and check `accountStatus`. Walk parent links to see which read-restricted ancestor actually gates a page.

The honest limits: there is no single API call for this, so the script is a real project (site-wide pagination, per-page restriction lookups within rate limits, retry handling), it needs scheduling and storage to be more than a one-off, and a single pass still cannot tell you what changed since the last audit: for history, you have to keep snapshots and diff them yourself.

🗂️ One option that fills the gap: Page-Restriction Governance

Disclosure: I work for Katabarwa Labs, and we build a small app for exactly this gap, so treat this as one option among whatever you evaluate.

Page-Restriction Governance runs that sweep on a daily schedule (and on demand) and keeps the result. Every restricted page is inventoried site-wide with the exact users and groups holding read and update on it, grouped by space, personal spaces included.

The review debris is flagged automatically: restrictions still naming deactivated accounts are marked as orphans, and pages sitting under a read-restricted ancestor carry an inheritance note pointing at the ancestor that actually gates them.

Every sweep is diffed against the previous snapshot, so the next audit is "review the delta": pages newly restricted or released, and subjects added to or removed from still-restricted pages, with the whole inventory exportable as audit-ready CSV, one row per page, operation, and subject.

Here is a short walkthrough of the app in action:

https://youtu.be/Ryf6RbaPg2c

It runs entirely on Atlassian Forge (Forge functions, a daily scheduled sweep, and Forge storage) inside your own Confluence Cloud tenant, so nothing leaves your instance, and lookups are bounded per run so even huge sites are scanned politely. Reporting is read-only. There is one opt-in write action: removing orphaned restrictions, meaning deleting deactivated accounts from the restrictions that still name them, always previewed as a dry run and executed only after an explicit checkbox-acknowledged confirm; since the account is deactivated and can never be re-added, that removal is permanent, and the app says so up front. Honest scope notes: the sweep covers current pages only (blog posts, whiteboards, databases, and archived or trashed content are not scanned in v1), space permissions themselves are out of scope, and coverage is always reported rather than assumed.

If a one-off script or a per-page check covers your review, use those. If "who can see this page, and since when?" should be a lookup, the listing is here: Page-Restriction Governance

If the app is close but the view should slice differently for your audits, tell us what that is and we will build it.