Care about security? We do too. Learn what Atlassian does and what you can do too.
Need to test security settings? Learn how with authentication policies.
Eager to configure? Read on about single sign-on.
Manage password policies for users? Set up two-step verification and idle session duration.
Stay on top of data across your organization with all the reports and tracking options we offer.
Learn about where your cloud product data is hosted and the types of data you can move.
Control how users and apps access your Atlassian cloud products.
Use classification levels to identify and categorize sensitive information in your organization.
Set up and manage BYOK encryption to add protection for your sensitive data.
Set up and manage data security policies to secure your organization’s data.
App access rule data blocking is an early access feature and subject to change. It is available only to participants in the Early Access Program (EAP).
This document is a work in progress and Atlassian will be making updates in the days to come.
Cloud customers have the flexibility to control apps' access to certain user-generated content when using Atlassian products. User-generated content includes items such as Confluence pages, blog posts, attachments, the organization of the content tree, and metadata about that content such as a page’s version history and ownership. While we encourage the use of apps to add functionality to our products, sometimes organizations that keep internal-only, sensitive, or confidential information in our products want to limit third-party app access to content in some spaces while leaving the apps free to function in others.
Using app access rules, customers can customize and extend Jira and Confluence while maintaining control over app access to certain content in specific spaces.
An app access rule is applied along with, not instead of, the user’s permissions. App functions that are available only to admin users cannot be used by users without those permissions, even when not blocked by an app access rule.
Adding an app access rule could have an impact on apps that previously used or relied on data in a space.
Apps that expect certain technical functionality like specific REST APIs and webhooks to always be available to them may no longer function properly, which can affect users' experience on your site.
The sections below provide a summary of:
The types of apps whose access to your data can be blocked by an app access rule.
The Atlassian product-specific functionality that is blocked when an app access rule is in effect for that app and space (or project), and the product functionality that is still allowed when an app access rule is in effect.
Blocking access with an app access rule will block the app’s access to certain data for installed apps (except system apps supplied by Atlassian), app updates, and future app installs, with a limited number of exceptions.
Specifically, you can apply an app access rule to block access to data for any installed app except:
apps built and supported by Atlassian that are pre-installed and required for proper product functionality, such as Smart Links
application links that are used to connect Confluence and Jira instances
apps that use Atlassian API tokens to access data
whenever an admin has enabled public anonymous access to a space or project, anonymous users will be able to interact with certain blocked apps accessing data in that space or project
a private app you are developing on Atlassian’s Forge platform, that you have installed in development or staging (an app access rule can only be applied to apps in production)
For a complete list of apps that may not be able to be blocked, see Apps that cannot be blocked by app access rules.
You can create an app access rule to limit an app’s ability to access and modify certain data in a Confluence space—particularly user-generated content such as pages, blog posts, attachments, and other content that a user adds to a Confluence space.
Apps whose access to data is not blocked by an app access rule will almost always use only a subset of the possible actions rather than all of them. For example, an app may need to read but not modify existing content, so it would not use functionality that creates, updates, or deletes content. To better understand the actions your apps perform when they have access to a space, check each app’s permissions which can be found on the app’s listing in the Integration Details section.
Apps that are blocked in a space by an app access rule may still take other actions that do not interact with user-generated content, such as updating the look and feel of Confluence. Global admin permissions may still be required to run certain apps. For example, if a Confluence user does not have admin permissions, they can’t use an app to perform administrative functions like adding users.
To view a detailed list of the app functionality that is blocked or still allowed when an access rule applies, see App Access for Confluence Cloud REST APIs.
Confluence app actions blocked by the app access rule
The following commonly-used Confluence functionality is blocked when an app is blocked by the app access rule. For the full list of blocked functionality see App Access for Confluence Cloud REST APIs .
Reading the body of, creating, updating, or deleting specific pieces of user-generated content, including permanently deleting content that has already been moved to the trash
comments (inline or page level)
custom (app-defined) content
Retrieving a list of, and returning details about
pages matching specified criteria, such as within a space or with a particular label
blog posts matching specified criteria, such as within a space or blog posts with a particular label
the children, ancestors (parent pages), attachments, or comments for a page
versions of a piece of content, including metadata such as the creator, last update date, and current version number
spaces, with details such as the space key, icon and name, description, permissions that apply to actions on the space, look and feel settings like theme, and the home page.
content matching a CQL search query
Reading, creating, updating, or deleting content properties stored by an app, for
comments (inline or page level)
custom (app-defined) content
Interacting with content in the following additional ways
reading, creating, updating, or deleting restrictions for a piece of content
moving or copying a piece of content to a new location
deleting a specific version of a piece of content, or restoring an old version as the current version of a piece of content
listing information such as
permissions for one or more pieces of content (an admin can list permissions for all pages; a non-admin user can only list their own permissions)
all pages in draft status
users who watched or liked a specific piece of content
content watched or liked by a specific user
tasks that appear on pages
retrieving content analytics containing the total number of views and total number of unique user views for a specific piece of content.
applying or removing labels from content
adding or removing a user as a watcher of a space or label
updating the details of a specific task
moving one or more pages in draft status to published status
Confluence app actions not blocked by the app access rule
There are some elements of product functionality and data that you cannot block with an app access rule. Generally, these are related to system-compiled or general data such as product look and feel customizations, Confluence templates, content “watch” information, and user and group management.
The following commonly-used Confluence functionality is not blocked when an app is blocked by the app access rule. For the full list of app functionality that cannot be blocked by an app access rule see App Access for Confluence Cloud REST APIs.
reading or creating audit records
getting or setting retention periods for audit records
listing all users who watched a space or label, or all spaces or labels watched by a particular user
adding or removing a particular user from the list of users watching a specific label or space
using dynamic modules that provide customized behavior to different users
listing all dynamic modules registered by this app
registering dynamic modules so that they can be used by this app, and removing them so that they can no longer be used by this app
listing all user groups on the app user’s current Confluence instance
reading information about a Confluence user group, including the group name and internal group ID
adding or removing Confluence user groups
listing the users who are members of a Confluence user group
adding and removing members from a Confluence user group
list the permitted operations for the space. Operations are actions that a user or API is permitted to take on a specific piece of content or space. Examples include, but are not limited to, create, read, update, delete, copy, export, and purge.
reading, resetting to the system default, or updating “look and feel” settings for a Confluence space (theme in use, color used for menus, and so on)
creating, updating the details of spaces
reading the details of a space including its name, homepage, status, type, and permissions for the space and pages, blog posts, comments, attachments, and applications within that space
listing the spaces in a Confluence instance
listing, adding and removing permissions for a user, group, or role to a particular space
listing, adding, updating, and removing application-defined properties of a space
listing all templates for a site or space, including blueprint templates
adding, updating, or removing a template
listing all admin-driven themes that an admin installs from the marketplace into a space or site
resetting a space’s theme to the global admin-driven theme
reading information about a theme
listing the current theme in use for a space, and updating which theme is used for a space
listing the global admin-driven theme for the Confluence instance
reading the details for one or more users at a time, such as their account ID, display name, space name, email address, profile picture, and Confluence permissions
reading the details of the Confluence instance’s anonymous user account, including its display name, profile picture or icon, and Confluence permissions (the anonymous user account provides generic user details for users who are not logged in to Confluence)
getting the account ID of the user who is running the app and reading the details for that user
listing information for a user such as:
the Confluence groups to which that user belongs
values of user properties defined at the site level for that user
creating, updating, and deleting user properties for a specific user
Was this helpful?