Forge Developer


Forge Developer

Last updatedApr 7, 2020

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. Note that this page only covers these topics at a high level; it does not provide instructions on how to implement security in your app.


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

Forge UI

Forge UI is the framework for building user interfaces for apps. Apps cannot interact with the user interface without using Forge UI.

Forge UI uses a declarative UI, where apps declare the UI components and implement functions to compose them. The functions run on the server-side and the components render on the server-side. Sandboxing UI functions like this makes the rendered UI secure, as no app code executes in the browser. Sandboxing also makes use of the security and isolation mechanisms that are used by the Forge back-end infrastructure. As a result, app developers don't have to worry about securing the app UI, as Forge UI produces trusted user interfaces by default.

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

  • App bundle: The app bundle is the packaged app code.
  • App isolate: App isolates are instantiated per request. Isolates provide per-request isolation within a single app. The app isolate is a v8 JavaScript isolate.
  • Node runtime: Forge apps run in AWS as lambdas. AWS Lambda provides per-app isolation.
  • Forge AWS account: The Forge platform runs lambdas using multiple AWS accounts to distribute the load. All of these accounts are separate from the other Atlassian services. Using dedicated accounts to run apps enables Forge to minimize privileges. This means that if an app escapes its sandbox due to a vulnerability, then running it in a less privileged account limits what it can do.

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.

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.

OAuth scopes

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

Scopes are an OAuth 2.0 mechanism that limit an app's access to a user's account. To access an Atlassian product REST API that uses OAuth 2.0 authentication, the app needs to request scopes in the manifest file. 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.

Rate this page: