Last updated Sep 27, 2023

Security requirements for cloud apps

Our goal is to create a high level of trust and security in the Atlassian Marketplace for our users. All cloud apps on the Atlassian Marketplace must adhere to the Marketplace Partner Agreement. As a Marketplace Partner, you're responsible for reviewing and updating your apps to make sure that they are compliant.

You are responsible for:

Meeting the security requirements outlined below.
Notifying us if you need help implementing a requirement.
Addressing vulnerabilities associated with these requirements within the timeframes for resolution, as defined in our Security Bug Fix Policy for Marketplace Apps.

To learn more, check out:

All cloud apps

The following table outlines our security requirements across all Marketplace cloud apps.

Also see implementation details specific to:

Connect apps
Forge Apps that Egress Data
Forge Apps
Trello Apps (Power-Ups)

TYPE OF REQUIREMENT	SECURITY REQUIREMENT
Authentication & Authorization	1. 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 Protection	2. 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 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 and code repository tools, such as Bitbucket and Github URL strings Referer headers Application logs
Application Security	6. 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.
Privacy	10. 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 Management	11. 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.

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 REQUIREMENT	SECURITY REQUIREMENT	IMPLEMENTATION DETAILS
Authentication & Authorization	1. 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` Read about implementing authorization here: Connect app authorization.
		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 Protection	2. 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 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 and code repository tools, such as Bitbucket and Github URL strings Referer headers Application logs	1. An application must never store secrets or authorization information in Jira Entity properties / Confluence Entity Properties.
Application Security	6. 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: An application must maintain control of each domain. 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. 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 the Content Security Policy (CSP) header. For example: `Content-Security-Policy: script-src 'self' https://connect-cdn.atl-paas.net; style-src 'self' https://connect-cdn.atl-paas.net` Do not use `unsafe-inline` or `unsafe-eval` directives in `script-src` when possible. This will make the policy ineffective against XSS vulnerabilities. You must include `https://connect-cdn.atl-paas.net` as a trusted source for `script-src` and `style-src`, to allow your Connect app to load the required resources from the Connect CDN.
		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.
Privacy	10. 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 Management	11. 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.

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 REQUIREMENT	SECURITY REQUIREMENT	IMPLEMENTATION DETAILS
Authentication & Authorization	1. 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.
Authentication & Authorization		2. Before making calls using `asApp()`, you must verify the expected permissions (for example, from product context) with the permissions REST APIs.
Data Protection	2. 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 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 and code repository tools, such as Bitbucket and Github URL strings Referer headers Application logs	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 Security	6. 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: An application must maintain control of each domain. 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. 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.
Privacy	10. 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 Management	11. 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.

Forge apps

This table gives guidance specific to Forge apps.

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

TYPE OF REQUIREMENT	SECURITY REQUIREMENT	IMPLEMENTATION DETAILS
Authentication & Authorization	1. 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.
Authentication & Authorization		2. Before making calls using `asApp()`, you must verify the expected permissions (for example, from product context) with the permissions REST APIs.
Data Protection	2. 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 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 and code repository tools, such as Bitbucket and Github URL strings Referer headers Application logs	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 Security	6. 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.
Privacy	10. 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 Management	11. 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.

Trello apps (Power-Ups)

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

TYPE OF REQUIREMENT	SECURITY REQUIREMENT	IMPLEMENTATION DETAILS
Authentication & Authorization	1. 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. Read about allowed origins here: Authorization
Data Protection	2. 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. Read about Power-Up scopes here: Getting and Setting Data
	5. An application must securely store and manage secrets, which include 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 and code repository tools, such as Bitbucket and Github URL strings Referer headers Application logs	1. Use `t.storeSecret` to store secrets such as oauth token. Read about secure data storage with Power-Ups here: Managing Secrets
Application Security	6. 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`: An application must maintain control of each domain. 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. 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.
Privacy	10. 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 Management	11. 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.

These security requirements were last revised on June 22, 2022. Refer to our changelog for more details.