Last updated Jul 12, 2023

Rate this page:


Customers need to have confidence in your software to use it. A key part of building trust is security, which encompasses a range of measures, including authentication and authorization, software execution, and data management. Forge facilitates and takes on responsibility for many of these things, conferring trust through its platform.

This page provides an overview of security for the Forge platform. This includes information on the architecture, features, and policies that contribute to security.

This page only covers these topics at a high level; it does not provide instructions on how to implement security in your app.


Atlassian is responsible for running the platform used by Forge applications. This includes enforcing what applications can and cannot do .

Forge apps can:

  • Run without interaction. For example, on a schedule, or in response to product events.
  • Be invoked directly by a web trigger.
  • Access the raw HTTP request in a web trigger.
  • Read/write all user-generated content (UGC), depending on which scopes are granted.

Forge apps cannot:

  • Act as a user without first getting user consent.
  • Increase scopes, permissions, and egress domains without reapproval by the site admin.
  • Access Atlassian user authentication information, such as credentials or sessions.
  • Access Atlassian APIs that haven't been permitted by the granted scopes.
  • Call product APIs for a product where the app isn't installed. For example, a Forge app installed on to Jira can't call Confluence.
  • Mutate user identity properties, such as changing user permissions or passwords.


The Forge architecture is designed to sandbox apps to control app execution. There are two main parts to this: user interface security and the app runtime.

We are developing a new native Node.js runtime to replace Forge's current runtime environment. This new runtime introduces several changes to the way security and egress controls work. Sandboxing and snapshots (including any related settings and restrictions) are no longer relevant in the new runtime as well. These changes may result in additional developer responsibilities to help uphold Forge's security.

This native Node.js runtime is available now as part of Forge's Early Access Program (EAP). For information about testing this new runtime, see Native Node.js runtime (EAP).

Forge’s EAP offers experimental features to selected users for testing and feedback purposes. These features are not supported or recommended for use in production environments. They are also subject to change without notice.

For more information, see Forge EAP, Preview, and GA.

User interface security

Forge offers two distinct options for building the user interface of your apps, custom UI and the UI kit. These options differ in terms of the complexity of the interactions and visual features that they cater for. Note that both custom UI and UI kit apps inherit modern security features to ensure high trust between Atlassian, developers, and users. As a result, app developers are able to create secure user interfaces by default.

Using custom UI, you can define your own user interface using static resources, such as HTML, CSS, JavaScript, and images. The Forge platform hosts your static resources, enabling your app to display custom UI on Atlassian products. Because custom UI apps are hosted by Atlassian, these apps can enforce sandboxing of the static resources that are run in the user's browser. This is done by using content security policy (CSP) headers that provide protection against common security vulnerabilities, such as cross-site scripting (XSS) and data injection. For your custom UI app to work as expected, your users must be on a CSP-compatible browser. See Custom UI security for more detail about these CSP headers.

With the UI kit, you'll be using a declarative UI to build your user interface, where apps implement functions to compose UI kit components. The functions run on the server-side. The UI kit components are already provided, so you don't need to design and create them, and they're always up to date with Atlassian design standards. Sandboxing UI functions in the UI kit makes the rendered UI secure, as no app code executes in the browser. This sandboxing also makes use of the security and isolation mechanisms that are used by the Forge back-end infrastructure.

App runtime

Controlling the app runtime is critical to security. The Forge runtime sandboxes the apps from the environment in which they execute. By running apps in isolated environments, the platform limits what apps can do. For example:

  • Apps cannot accidentally leak customer data across sites.
  • Apps cannot interfere with or modify other running apps.

To understand how this works in detail, see the diagram and notes on the Forge app sandbox below:

Diagram of Forge app sandbox

Data management

The Forge platform enables secure data management through its architecture and the way it handles data. This includes data isolation to prevent leaks as well as data handling policies for the Forge environments.

Data isolation

Data isolation for apps is necessary in a cloud environment. The Atlassian cloud products are multi-tenant, so apps need to be multi-tenant. However, this means that apps can potentially mix customer data. For example, two customers use an app that uses a global object to cache data by issue key. Issue keys are not globally unique, therefore data could leak from one customer to another.

The Forge platform prevents these types of scenarios by sandboxing apps, as described in the App runtime section. Since apps are sandboxed, app calls occur in separate instances of the app. This means that data is isolated at the runtime level, preventing data leaking.


Forge ensures that data is handled responsibly by providing different environments for app developers. An environment is a version of the app that has its own code, manifest, modules, outbound auth container, environment variables, and installations. Forge provides three static environments development, staging, and production, which are set up when the app is created. Policies for reading data are enforced on these environments.

  • development: This is the default environment used by a developer. Developers can read logs and use tunneling.
  • staging: This environment is typically used for continuous deployment, rather than development. However, it is the same as development in terms of restrictions on reading data.
  • production: This is the environment where apps should be installed for use with production Cloud sites. Developers cannot access logs and cannot use tunneling.

Enforcing these policies ensures that developers cannot get access to customer data without consent.

Simple and secure authentication

Authentication is a fundamental part of security, but it can be complicated to implement and can open up the app to security vulnerabilities. Forge controls the app runtime, which enables it to provide managed APIs that apps can use to make secure calls to REST APIs.

Using managed APIs means that third-party code is never trusted with user credentials. API calls are automatically authenticated on behalf of the app by the surrounding Forge infrastructure. This also means that making API calls is much simpler.

A Forge app using the managed APIs can make requests on behalf of a user. Before permitting such an API request, the runtime ensures that the user has agreed to the required access. If not, the user is shown what access the app requires. After the user has agreed and provided access, future API requests on behalf of the user are passed automatically.

The app may also include content and external permissions so the app can send data to and retrieve data from external domains. This covers both custom UI apps and Function as a Service (FaaS) functions. If the app requires such permissions, users will also need to consent to them before they can use the app.

When an app changes its access requirements, users are prompted to review the access and provide consent again. An app defines its access requirements in the manifest file in the form of OAuth 2.0 scopes, content, and external permissions.

OAuth scopes

Forge apps use OAuth 2.0 protocols when authenticating with Jira platform, Jira Software, and Confluence REST APIs.

Scopes are an OAuth 2.0 mechanism that enables an app to access the data manipulated by a REST API operation. To access an Atlassian product operation that uses OAuth 2.0 authentication, the app needs to request the scopes required by the operation in the manifest file. Scopes then provide administrators and users information about the data an app accesses. This enables administrators and users to decide whether they want to install the app. See Add scopes to call an Atlassian REST API for details.

If an app doesn't request any scopes, the app doesn't have access to OAuth 2.0 protected resources. This follows the principle of least privilege and helps to retain the trust of your users.

External providers

Beyond authentication with Atlassian APIs, Forge supports managed OAuth 2.0 authentication with external identity providers that support OAuth 2.0 authorization code grants, such as Google or Slack.

When using external providers, Forge apps act as the OAuth 2.0 client connecting to an external resource. This enables a Forge app to request information from third-party services securely using the familiar fetch function, while the platform handles getting and rotating OAuth 2.0 tokens automatically.

An app using external authentication provides a connection across multiple Atlassian products with shared authentication handled by the Forge platform. However, apps never have direct access to the OAuth 2.0 tokens. Instead, apps use the withProvider method to have the Forge platform automatically send tokens with each request.

Learn how to integrate with an external provider in the external authentication tutorial.

Rate this page: