App permissions

Confluence shows a list of permissions when you install the app. This page gives the reasoning behind each entry: which API call needs it, and why the app does not ask for less.

The short version: seven permissions, five of them read-only. The app declares no outbound network access at all, which is why Atlassian grants it the Runs on Atlassian designation — there is no path by which your content can reach a system the vendor operates.

The list

Two permissions in that list are the classic, broader kind (read:confluence-content.summary and write:confluence-content); the rest are granular. That mix is deliberate and explained under each entry below — it follows the API version each call belongs to, not a preference.

Read permissions

read:confluence-content.summary

Reads content metadata: what exists, what type it is, which space it belongs to, how large it is. The .summary suffix is meant literally — it excludes page bodies, which is why the app has to ask separately for those (see read:page:confluence).

The broader read:confluence-content.all would have covered this and the page bodies in one permission. It was not requested: it also grants access to comments, drafts and everything else attached to content the app has no reason to look at.

read:confluence-space.summary

Space names, keys and IDs. The app needs this for two things: attributing storage to the right space in the site-wide breakdown, and translating a space key into the space ID that the newer API endpoints filter on.

It is the summary variant, so it does not include space permissions, settings or content. The app never modifies a space.

search:confluence

Backs the site-wide and space-wide scan. The app queries the Confluence search index for attachments (/rest/api/content/search), which is the only way to enumerate them beyond a single page.

read:attachment:confluence

Reads an individual attachment version: GET /wiki/api/v2/attachments/{id}?version=N. This is the call that produces the central number in the app — the total billed size across all versions of a file. Without it there is no per-version size, and the app could only show what the Confluence attachment list already shows: the current version.

read:confluence-content.summary does not cover this endpoint. It belongs to the newer API namespace, which rejects classic permissions outright.

The same permission also lets the app fetch attachment thumbnails, so the preview in the table works without your browser having to authenticate separately against the media CDN.

read:page:confluence

Reads page bodies: GET /wiki/api/v2/pages/{id}?body-format=…. This is what makes the reference status possible — whether any page still embeds or links to a file. The app scans the body of each page in the scope and matches attachment filenames against it.

Without this permission there is no reference scan, and no way to tell a file that a reader opens every week from one that nothing points at any more. The alternative that would have covered it, read:confluence-content.all, is far broader than reading page bodies.

Write permissions

Both write permissions are only ever used on something you selected and confirmed. The app never deletes on its own, and it acts as the signed-in user — it can delete only what you could already delete in Confluence yourself.

write:confluence-content

Carries exactly one call:

DELETE /wiki/rest/api/content/{id}/version/{versionNumber}

This removes a superseded version of an attachment and leaves the current one in place. It is the operation that frees the bulk of the storage most sites can recover.

This is the broadest permission the app asks for, and the reason is the endpoint: removing a single old version exists only in the older API namespace. There is no newer equivalent — the newer API only knows how to delete a whole attachment, which would take the current version with it. For that older endpoint, Atlassian documents write:confluence-content as the permission to use.

delete:attachment:confluence

Carries two calls, both in the newer API namespace:

DELETE /wiki/api/v2/attachments/{id}              → moves it to the trash
DELETE /wiki/api/v2/attachments/{id}?purge=true   → removes it permanently

The first is what happens when you delete an attachment in the app normally; it stays recoverable from the space's trash. The second is for when you need the space back immediately, because trashed attachments still count against your quota until the trash is emptied. See Free up space.

This one is granular rather than classic — the opposite choice from the permission above, for the same underlying reason: it follows the API version the call belongs to.

What the app cannot do

• Act with more rights than you have. Every call runs as the signed-in user. The app shows and deletes only what that user could already reach in Confluence. Installing it grants nobody access they did not have before.
• Send anything anywhere. No outbound network access is declared, and Atlassian enforces that declaration. Your content does not leave your Confluence site.
• Store your content. The app keeps no copy of what it scans. Close the tab and the analysis is gone; open it again and it is recomputed.
• Delete without you. There is no scheduled job and no background task. Every deletion follows a selection and a confirmation in the interface.

When permissions change

Forge apps update automatically on your site, but a version that requests different permissions does not. Confluence holds it back and asks an administrator to approve the change first, so the list above cannot grow quietly.