The premise in this RFC is that the guest user feature creates a unique permissions situation for which the response should be the blocking of all third-party apps.
The RFC mentions the following decision point:
During the Beta, we identified a potential data privacy concern where Guest users, who are given access to a single space in a Confluence instance, could potentially view and access information across any spaces using Apps. The main security issue is with Apps having more access than Guest users. When an App displays something on a page/space, it can get data from other spaces that it has access to (by using the app’s permission), and exposing that to Guest users. Apps are installed and priced for all users wall to wall within an instance and there’s no way today to:
When the guest user feature was announced, Atlassian said that there would be no change to underlying permissions model. As far as I can tell, this is still mostly true. Aside from the ability to at-mention users or see the user directory, I do not see how guest users are any different from (say) a paid user who only has access to one or two spaces.
Yes, app user accounts generally have more permission than the current user account, but this has always been the case, and it is not something new for guest users.
In both scenarios (a guest user and a regular user with a limited permission set), it is possible for an app to accidentally leak information. And as Remie pointed out above, an app doesn’t even need to have “ADMIN” scope to do this: simply making a request from the back end using its own app credentials (rather than impersonating with ACT_AS_USER) could be sufficient to inadvertently disclose information, since the app user typically has system-wide access.
So why are guest users treated differently here? This change would add significant handicaps to the user experience for partners, and apps that do handle permissions properly will still be penalized in terms of excessive support tickets and broken features.
For apps that do not handle permissions properly, this issue can already be addressed through bug bounties and raising incident tickets in the Atlassian ecosystem security project. And these apps were broken to begin with anyway, with or without the guest feature.
For the slight permission differences (like user directory access) that require apps to act differently from the current permission model, Atlassian provided a halfway solution of introducing a context parameter, but when the community asked for a way to get the “guest user status” from the user REST API so that the user’s status could be determined in other contexts, I could not find any response.
If Atlassian still wants to go ahead with this plan, I second the other calls to allow apps to opt-in to being accessible by guest users through the descriptor/manifest. Apps that are not regularly maintained will be excluded from guest access by default, which solves your problem, and those apps who do want to support guest users will have to make manual changes and effectively declare that they are compliant.
Also, the post suggests that guest-disabled apps will still receive webhooks, and that the apps may want to handle webhooks differently for guest users. I admit that haven’t looked recently, but I don’t believe that guest users are actually identified as such in the webhook payload, so it is not currently possible to do this (absent the REST API I mentioned above).
PS: There is some irony here in this app-blocking “feature” being rolled out only to Connect apps and not Forge…not just the irony of the rollout being an exception to the “Forge-first” mantra, but it’s especially poignant in that Forge does not even support the ACT_AS_USER feature that is essential for server-side permissions trimming, which is what vendors need to prevent this type of vulnerability.
–
Edit: OK, the last paragraph is more calling out a Connect-on-Forge shortcoming, rather than Forge overall (which I admit does have asUser())…but this is still a problem for Connect-on-Forge, as well as straight Forge for non-UIKit modules, background processing, etc.