Last updated Jul 25, 2022

Rate this page:

# Overview

At Atlassian, our goal is to create a high level of trust and security in the Atlassian Marketplace for our users. To ensure security across the Marketplace, the requirements on this page are mandatory for all Marketplace cloud applications to adhere per the Marketplace Partner Agreement. You are responsible to review and update your apps to make sure that they are compliant. We expect you to:

For commonly asked questions, reference our FAQ page. We have also provided additional information on these security requirements.

Security requirements for all Marketplace cloud applications

The following table outlines our security requirements by the type of requirement.

For implementation details specific to development platform, follow these links:


TYPE OF REQUIREMENTSECURITY REQUIREMENT
Authentication & Authorization1. An application must authenticate and authorize every request on all endpoints exposed. Anonymous access to application endpoints and resources can be allowed in scenarios where it is needed.
Data Protection2. Any Atlassian End User Data:
  • stored by an application outside of the Atlassian product or users' browser must ensure full disk encryption at-rest.
  • accessed by an application or a service should be authenticated and authorized appropriately.
For more information about Atlassian End User Data, reference our Atlassian Developer Terms or Trello Developer Terms.
3. An application must use TLS version 1.2 (or higher) to encrypt all of its traffic, and enable HSTS with a minimum age of one year.

We highly recommend only allowing clients to connect using ciphersuites listed under the “Intermediate compatibility” section of the latest Mozilla’s Server Side TLS guidance. These ciphersuites provide a good balance of security and compatibility with older clients. If you choose to only implement a subset of the ciphersuites, you should thoroughly test any production changes to avoid customer impact.

4. An application must follow the “Principle of Least Privilege”, when requesting app scopes. This means that an application should only request scopes required to perform its intended functionality, and nothing more.
5. An application must securely store and manage secrets, which include JWTs, OAuth tokens, Trello tokens, sharedSecret, API keys, and encryption keys. They cannot be stored in places that are easily accessible. Examples of places include:
  • Source code
  • URL strings
  • Referer headers
  • Application logs
  • Code repositories, such as Bitbucket and Github

Application Security6. An application must maintain and securely configure domains where the application is hosted.
7. When applicable, an application must enable security headers and cookie security attributes.
8. An application must validate and sanitize all untrusted data and treat all user input as unsafe to mitigate injection-related vulnerabilities. Untrusted data is any input that can be manipulated to contain a web attack payload.
9. An application must not use versions of third-party libraries and dependencies with known critical or high vulnerabilities. When vulnerabilities in these libraries and dependencies are discovered, application developer must remediate them as quickly as possible.
Privacy10. An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens.

If an app is currently requesting or storing Atlassian API tokens in order to access a REST API that does not currently support authentication from apps, the app developer can notify Atlassian and receive a temporary waiver for this requirement while Atlassian makes the proper changes to our API to support authenticated requests from apps. Once the API supports approved authentication methods, the app developer will be given a reasonable amount of time to migrate away from using Atlassian API tokens. This requirement does not prohibit apps from storing credentials used to access non-Atlassian applications.


Vulnerability Management11. You must know, understand, and follow our Security Bug Fix Policy. The following page explains Atlassian’s Security Bug Fix Policy for Marketplace Apps.
12. You must notify Atlassian of all security incidents via ECOHELP. The following guide explains how to handle a security incident.
13. You must identify at least one email as a security contact and have them create an account on ecosystem.atlassian.net so that they are notified about vulnerabilities in the app via Atlassian Marketplace Security (AMS) tickets. The following guide explains how to get access to AMS.

Please note that an admin can also be listed as a security contact.


Implementation Details for Connect Apps

This table gives guidance specific to Connect apps.

FRAMEWORK SUPPORTED means that this implementation detail is supported by either the ACE or ACSB frameworks provided by Atlassian. Please note that these requirements are not automatically met if you are using these frameworks.


TYPE OF REQUIREMENTSECURITY REQUIREMENTIMPLEMENTATION DETAILS
Authentication & Authorization1. An application must authenticate and authorize every request on all endpoints exposed. Anonymous access to application endpoints and resources can be allowed in scenarios where it is needed.1. An application must always use JWT as the authentication type to validate the application identity and the integrity of the request. FRAMEWORK SUPPORTED
  • Read about implementing authentication here: Understanding JWT.

  • Exception: It is permissible to set authentication type to None in the app descriptor if all of the endpoints in the descriptor serve only static content.

2. A JWT token must be validated on the server-side for every authenticated request. Validate all user permissions to ensure that only permitted users can execute actions within an application.FRAMEWORK SUPPORTED
3. An application must always check for JWT token expiration time. Expired tokens must be rejected. FRAMEWORK SUPPORTED
4. An application must always validate install/uninstall lifecycle requests. FRAMEWORK SUPPORTED
5. An application must not accept context JWTs in module or lifecycle endpoints.

Data Protection2. Any Atlassian End User Data:
  • stored by an application outside of the Atlassian product or users' browser must ensure full disk encryption at-rest.
  • accessed by an application or a service should be authenticated and authorized appropriately.
For more information about Atlassian End User Data, reference our Atlassian Developer Terms or Trello Developer Terms.
There are no specific implementation details.
3. An application must use TLS version 1.2 (or higher) to encrypt all of its traffic, and enable HSTS with a minimum age of one year.

We highly recommend only allowing clients to connect using ciphersuites listed under the “Intermediate compatibility” section of the latest Mozilla’s Server Side TLS guidance. These ciphersuites provide a good balance of security and compatibility with older clients. If you choose to only implement a subset of the ciphersuites, you should thoroughly test any production changes to avoid customer impact.

1. When possible, add the includeSubDomain directive in the HSTS policy definition.
4. An application must follow the “Principle of Least Privilege”, when requesting app scopes. This means that an application should only request scopes required to perform its intended functionality, and nothing more.Read about Connect scopes here: Scopes for Connect apps
5. An application must securely store and manage secrets, which include JWTs, OAuth tokens, Trello tokens, sharedSecret, API keys, and encryption keys. They cannot be stored in places that are easily accessible. Example of places include:
  • Source code
  • URL strings
  • Referer headers
  • Application logs
  • Code repositories, such as Bitbucket and Github

1. An application must never store secrets or authorization information in Entity properties / Content Properties.
Application Security6. An application must maintain and securely configure domains where the application is hosted.The following needs to be true for the baseUrl listed in an application’s app descriptor:
  1. An application must maintain control of each domain.
  2. An application owner must maintain valid TLS certificates of the domains where an application is hosted, and the domain must be signed by a trusted Certificate Authority.
  3. An application’s DNS configuration for subdomains must reference services that are in use.
7. When applicable, an application must enable security headers and cookie security attributes.1. An application must set Content Security Policy (CSP) header.Content-Security-Policy: script-src
  • Do not use unsafe-inline or unsafe-eval directives in script-src when possible. This will make the policy ineffective against XSS vulnerabilities.
2. An application must implement the Referrer-Policy header.
  • The header must not be configured to no-referrer-when-downgrade or unsafe-url. We recommend using no-referrer or strict-origin-when-cross-origin.
3. An application must disable caching on all HTTPS pages that contain sensitive data by using no-cache and no-store instead of private in the cache control header.
4. For session-related cookies, an application must set HttpOnly and Secure attributes when sending Set-Cookie headers.
8. An application must validate and sanitize all untrusted data and treat all user input as unsafe to mitigate injection-related vulnerabilities. Untrusted data is any input that can be manipulated to contain a web attack payload.1. An application must validate the qsh to prevent URL tampering.
2. When possible, an application using template engines must not use dangerous functions or modules that lead to arbitrary code execution. When there is a business requirement to use these functions, sandbox it inside an isolated, locked-down environment.
9. An application must not use versions of third-party libraries and dependencies with known critical or high vulnerabilities. When vulnerabilities in these libraries and dependencies are discovered, an application owner must remediate them as quickly as possible.
There are no specific implementation details.
Privacy10. An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens.

If an app is currently requesting or storing Atlassian API tokens in order to access a REST API that does not currently support authentication from apps, the app developer can notify Atlassian and receive a temporary waiver for this requirement while Atlassian makes the proper changes to our API to support authenticated requests from apps. Once the API supports approved authentication methods, the app developer will be given a reasonable amount of time to migrate away from using Atlassian API tokens. This requirement does not prohibit apps from storing credentials used to access non-Atlassian applications.


There are no specific implementation details.
Vulnerability Management11. You must know, understand, and follow our Security Bug Fix Policy. The following page explains Atlassian’s Security Bug Fix Policy for Marketplace Apps.
There are no specific implementation details.
12. You must notify Atlassian of all security incidents via ECOHELP. The following guide explains how to handle a security incident.
1. If the security incident involves sharedSecret leakage, immediately notify Atlassian and request to rotate the sharedSecret through ECOHELP within 24 hours.
13. You must identify at least one email as a security contact and have them create an account on ecosystem.atlassian.net so that they are notified about vulnerabilities in the app via Atlassian Marketplace Security (AMS) tickets. The following guide explains how to get access to AMS.

Please note that an admin can also be listed as a security contact.


There are no specific implementation details.

Implementation Details for Forge Apps that Egress Data

This table gives guidance specific to Forge apps that egress data.

Forge apps that egress data are defined as Forge apps that interact with external services, including APIs, data storage, and compute services. This class of apps has different implementation considerations for some requirements; because of this, we have listed implementation details separately from Forge apps that do not egress data.

PLATFORM PROVIDED means that Atlassian’s Forge platform covers this security requirement.


TYPE OF REQUIREMENTSECURITY REQUIREMENTIMPLEMENTATION DETAILS
Authentication & Authorization1. An application must authenticate and authorize every request on all endpoints exposed. Anonymous access to application endpoints and resources can be allowed in scenarios where it is needed.1. An application must default to using asUser() when performing an operation on behalf of the user.
2. Before making calls using asApp(), you must verify the expected permissions (for example, from product context) with the permissions REST APIs.
Data Protection2. Any Atlassian End User Data:
  • stored by an application outside of the Atlassian product or users' browser must ensure full disk encryption at-rest.
  • accessed by an application or a service should be authenticated and authorized appropriately.
For more information about Atlassian End User Data, reference our Atlassian Developer Terms or Trello Developer Terms.
There are no specific implementation details.
3. An application must use TLS version 1.2 (or higher) to encrypt all of its traffic, and enable HSTS with a minimum age of one year.

We highly recommend only allowing clients to connect using ciphersuites listed under the “Intermediate compatibility” section of the latest Mozilla’s Server Side TLS guidance. These ciphersuites provide a good balance of security and compatibility with older clients. If you choose to only implement a subset of the ciphersuites, you should thoroughly test any production changes to avoid customer impact.

There are no specific implementation details.
4. An application must follow the “Principle of Least Privilege”, when requesting app scopes. This means that an application should only request scopes required to perform its intended functionality, and nothing more.Read about Forge scopes here: Permissions
5. An application must securely store and manage secrets, which include JWTs, OAuth tokens, Trello tokens, sharedSecret, API keys, and encryption keys. They cannot be stored in places that are easily accessible. Example of places include:
  • Source code
  • URL strings
  • Referer headers
  • Application logs
  • Code repositories, such as Bitbucket and Github

  1. Use encrypted environment variables and storage.setSecret to store secrets in your app. PLATFORM PROVIDED
  • Read about secure data storage on Forge here: Storage

Application Security6. An application must maintain and securely configure domains where the application is hosted.The following needs to be true when an application makes calls to domains owned by the application owner:
  1. An application must maintain control of each domain.
  2. An application owner must maintain valid TLS certificates of the domains where an application is hosted, and the domain must be signed by a trusted Certificate Authority.
  3. An application’s DNS configuration for subdomains must reference services that are in use.
7. When applicable, an application must enable security headers and cookie security attributes.PLATFORM PROVIDED
8. An application must validate and sanitize all untrusted data and treat all user input as unsafe to mitigate injection-related vulnerabilities. Untrusted data is any input that can be manipulated to contain a web attack payload.There are no specific implementation details.
9. An application must not use versions of third-party libraries and dependencies with known critical or high vulnerabilities. When vulnerabilities in these libraries and dependencies are discovered, an application owner must remediate them as quickly as possible.
There are no specific implementation details.
Privacy10. An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens.

If an app is currently requesting or storing Atlassian API tokens in order to access a REST API that does not currently support authentication from apps, the app developer can notify Atlassian and receive a temporary waiver for this requirement while Atlassian makes the proper changes to our API to support authenticated requests from apps. Once the API supports approved authentication methods, the app developer will be given a reasonable amount of time to migrate away from using Atlassian API tokens. This requirement does not prohibit apps from storing credentials used to access non-Atlassian applications.


There are no specific implementation details.
Vulnerability Management11. You must know, understand, and follow our Security Bug Fix Policy. The following page explains Atlassian’s Security Bug Fix Policy for Marketplace Apps.
There are no specific implementation details.
12. You must notify Atlassian of all security incidents via ECOHELP. The following guide explains how to handle a security incident.
There are no specific implementation details.
13. You must identify at least one email as a security contact and have them create an account on ecosystem.atlassian.net so that they are notified about vulnerabilities in the app via Atlassian Marketplace Security (AMS) tickets. The following guide explains how to get access to AMS.

Please note that an admin can also be listed as a security contact.


There are no specific implementation details.

Implementation Details for Forge Apps

This table gives guidance specific to Forge apps.

PLATFORM PROVIDED means that Atlassian’s Forge platform covers this security requirement.


TYPE OF REQUIREMENTSECURITY REQUIREMENTIMPLEMENTATION DETAILS
Authentication & Authorization1. An application must authenticate and authorize every request on all endpoints exposed. Anonymous access to application endpoints and resources can be allowed in scenarios where it is needed.1. An application must default to using asUser() when performing an operation on behalf of the user.
2. Before making calls using asApp(), you must verify the expected permissions (for example, from product context) with the permissions REST APIs.
Data Protection2. Any Atlassian End User Data:
  • stored by an application outside of the Atlassian product or users' browser must ensure full disk encryption at-rest.
  • accessed by an application or a service should be authenticated and authorized appropriately.
For more information about Atlassian End User Data, reference our Atlassian Developer Terms or Trello Developer Terms.
PLATFORM PROVIDED
3. An application must use TLS version 1.2 (or higher) to encrypt all of its traffic, and enable HSTS with a minimum age of one year.

We highly recommend only allowing clients to connect using ciphersuites listed under the “Intermediate compatibility” section of the latest Mozilla’s Server Side TLS guidance. These ciphersuites provide a good balance of security and compatibility with older clients. If you choose to only implement a subset of the ciphersuites, you should thoroughly test any production changes to avoid customer impact.

PLATFORM PROVIDED
4. An application must follow the “Principle of Least Privilege”, when requesting app scopes. This means that an application should only request scopes required to perform its intended functionality, and nothing more.Read about Forge scopes here: Permissions
5. An application must securely store and manage secrets, which include JWTs, OAuth tokens, Trello tokens, sharedSecret, API keys, and encryption keys. They cannot be stored in places that are easily accessible. Example of places include:
  • Source code
  • URL strings
  • Referer headers
  • Application logs
  • Code repositories, such as Bitbucket and Github

  1. Use encrypted environment variables and storage.setSecret to store secrets in your app. PLATFORM PROVIDED
  • Read about secure data storage on Forge here: Storage

Application Security6. An application must maintain and securely configure domains where the application is hosted.This requirement does not apply to this app type.
7. When applicable, an application must enable security headers and cookie security attributes.PLATFORM PROVIDED
8. An application must validate and sanitize all untrusted data and treat all user input as unsafe to mitigate injection-related vulnerabilities. Untrusted data is any input that can be manipulated to contain a web attack payload.There are no specific implementation details.
9. An application must not use versions of third-party libraries and dependencies with known critical or high vulnerabilities. When vulnerabilities in these libraries and dependencies are discovered, an application owner must remediate them as quickly as possible.
There are no specific implementation details.
Privacy10. An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens.

If an app is currently requesting or storing Atlassian API tokens in order to access a REST API that does not currently support authentication from apps, the app developer can notify Atlassian and receive a temporary waiver for this requirement while Atlassian makes the proper changes to our API to support authenticated requests from apps. Once the API supports approved authentication methods, the app developer will be given a reasonable amount of time to migrate away from using Atlassian API tokens. This requirement does not prohibit apps from storing credentials used to access non-Atlassian applications.


There are no specific implementation details.
Vulnerability Management11. You must know, understand, and follow our Security Bug Fix Policy. The following page explains Atlassian’s Security Bug Fix Policy for Marketplace Apps.
There are no specific implementation details.
12. You must notify Atlassian of all security incidents via ECOHELP. The following guide explains how to handle a security incident.
There are no specific implementation details.
13. You must identify at least one email as a security contact and have them create an account on ecosystem.atlassian.net so that they are notified about vulnerabilities in the app via Atlassian Marketplace Security (AMS) tickets. The following guide explains how to get access to AMS.

Please note that an admin can also be listed as a security contact.


There are no specific implementation details.

Implementation Details for Trello Apps (Power-Ups)

This table gives guidance specific to Trello Apps (Power-Ups).


TYPE OF REQUIREMENTSECURITY REQUIREMENTIMPLEMENTATION DETAILS
Authentication & Authorization1. An application must authenticate and authorize every request on all endpoints exposed. Anonymous access to application endpoints and resources can be allowed in scenarios where it is needed.1. Secure the communication between the Power-Up and your server by using t.jwt() to include JWT token with requests
  • Read about implementing authentication here: t.jwt(opts)
2.JWT tokens must be properly validated on the server-side to ensure that the JWT signature is (a) valid, (b) not expired, (c) it comes from your Power-Up, and (d) is a particular Trello user.
3. When creating an API key for use with Trello’s REST API, set the appropriate allowed origins for your application.
Data Protection2. Any Atlassian End User Data:
  • stored by an application outside of the Atlassian product or users' browser must ensure full disk encryption at-rest.
  • accessed by an application or a service should be authenticated and authorized appropriately.
For more information about Atlassian End User Data, reference our Atlassian Developer Terms or Trello Developer Terms.
There are no specific implementation details.
3. An application must use TLS version 1.2 (or higher) to encrypt all of its traffic, and enable HSTS with a minimum age of one year.

We highly recommend only allowing clients to connect using ciphersuites listed under the “Intermediate compatibility” section of the latest Mozilla’s Server Side TLS guidance. These ciphersuites provide a good balance of security and compatibility with older clients. If you choose to only implement a subset of the ciphersuites, you should thoroughly test any production changes to avoid customer impact.

1. When possible, add the includeSubDomain directive in the HSTS policy definition.
4. An application must follow the “Principle of Least Privilege”, when requesting app scopes. This means that an application should only request scopes required to perform its intended functionality, and nothing more.1. When making use of t.set() from the Power-Up client library, the shared scope should never be used to store data that should be kept secret. Please note that data stored in the shared scope is readable by any user who can view the board.
5. An application must securely store and manage secrets, which include JWTs, OAuth tokens, Trello tokens, sharedSecret, API keys, and encryption keys. They cannot be stored in places that are easily accessible. Example of places include:
  • Source code
  • URL strings
  • Referer headers
  • Application logs
  • Code repositories, such as Bitbucket and Github

1. Use t.storeSecret to store secrets such as oauth token.
Application Security6. An application must maintain and securely configure domains where the application is hosted.The following needs to be true for the domain listed in an application’s iFrameConnectorURL:
  1. An application must maintain control of each domain.
  2. An application owner must maintain valid TLS certificates of the domains where an application is hosted, and the domain must be signed by a trusted Certificate Authority.
  3. An application’s DNS configuration for subdomains must reference services that are in use.
7. When applicable, an application must enable security headers and cookie security attributes.1. An application must set Content Security Policy (CSP) header.Content-Security-Policy: script-src
  • Do not use unsafe-inline or unsafe-eval directives in script-src when possible. This will make the policy ineffective against XSS vulnerabilities.
2. An application must implement the Referrer-Policy header.
  • The header must not be configured to no-referrer-when-downgrade or unsafe-url. We recommend using no-referrer or strict-origin-when-cross-origin.
3. An application must disable caching on all HTTPS pages that contain sensitive data by using no-cache and no-store instead of private in the cache control header.
4. For session-related cookies, an application must set HttpOnly and Secure attributes when sending Set-Cookie headers.
8. An application must validate and sanitize all untrusted data and treat all user input as unsafe to mitigate injection-related vulnerabilities. Untrusted data is any input that can be manipulated to contain a web attack payload.1. You may either use provided t.safe(rawHTML) or your framework of choice to sanitize the content before insertion into the DOM.
9. An application must not use versions of third-party libraries and dependencies with known critical or high vulnerabilities. When vulnerabilities in these libraries and dependencies are discovered, an application owner must remediate them as quickly as possible.
There are no specific implementation details.
Privacy10. An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens.

If an app is currently requesting or storing Atlassian API tokens in order to access a REST API that does not currently support authentication from apps, the app developer can notify Atlassian and receive a temporary waiver for this requirement while Atlassian makes the proper changes to our API to support authenticated requests from apps. Once the API supports approved authentication methods, the app developer will be given a reasonable amount of time to migrate away from using Atlassian API tokens. This requirement does not prohibit apps from storing credentials used to access non-Atlassian applications.


1. Power-Ups should only store Trello API tokens obtained after user consent is granted via the Trello authorization flow.
Vulnerability Management11. You must know, understand, and follow our Security Bug Fix Policy. The following page explains Atlassian’s Security Bug Fix Policy for Marketplace Apps.
There are no specific implementation details.
12. You must notify Atlassian of all security incidents via ECOHELP. The following guide explains how to handle a security incident.
There are no specific implementation details.
13. You must identify at least one email as a security contact and have them create an account on ecosystem.atlassian.net so that they are notified about vulnerabilities in the app via Atlassian Marketplace Security (AMS) tickets. The following guide explains how to get access to AMS.

Please note that an admin can also be listed as a security contact.


This requirement does not yet apply to this app type.

Security requirements were last revised by the Atlassian on June 22, 2022. Refer to the changelog here for more details.

Rate this page: