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)
3LO (OAuth) Apps

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.
	10. An application must not use EOL (end-of-life) Node.js runtimes and unmaintained or deprecated libraries, especially those without upstream fixes.
Privacy	11. An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens. If an app needs to request or store Atlassian API tokens in order to access a REST API that does not currently support authentication from apps, the app developer can request Atlassian to make the changes to our API to support authenticated requests from apps. If your existing Connect app currently collects user API tokens, you are required to migrate to Forge, with tokens stored in Forge encrypted storage, while we work with you to add the necessary support to authenticate using Forge Authentication. This requirement does not prohibit apps from storing credentials used to access non-Atlassian applications. For more details, read our FAQ.
Vulnerability Management	12. You must know, understand, and follow our Security Bug Fix Policy. The following page explains Atlassian’s Security Bug Fix Policy for Marketplace Apps.
	13. You must notify Atlassian of all security incidents via ECOHELP. The following guide explains how to handle a security incident.
	14. 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 needs to request or store Atlassian API tokens in order to access a REST API that does not currently support authentication from apps, the app developer can request Atlassian to make the changes to our API to support authenticated requests from apps. If your existing Connect app currently collects user API tokens, you are required to migrate to Forge, with tokens stored in Forge encrypted storage, while we work with you to add the necessary support to authenticate using Forge Authentication. This requirement does not prohibit apps from storing credentials used to access non-Atlassian applications. For more details, read our FAQ.	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.
		2. Before making calls using `asApp()`, you must verify the expected permissions (for example, from product context) with the permissions REST APIs.
		3. The Forge remote backend must validate authenticity, expiration, and context from the Forge Invocation Token (FIT) to ensure requests originate from Atlassian and are intended for your app.
		4. The Forge remote backend must verify the expected user permissions before executing actions that require user context.
		5. External OAuth2 clients used by an application must use Forge's OAuth2 Providers unless a required capability is not supported, and must be configured as confidential clients (requiring a `client_secret` to obtain or refresh access tokens) whenever the external OAuth2 provider supports both public and confidential client types for the relevant OAuth2 flows.
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
	6. Any Atlassian End User Data written to application logs must exclude Personally Identifiable Information (PII), credentials, and sensitive data.	There are no specific implementation details.
	7. An application must ensure strict tenant isolation during runtime. Data or variables from one tenant must not be accessible to another, including via runtime artifacts.	The boundaries of tenant safety and data handling are defined in the Shared responsibility model.
Application Security	8. 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.
	9. When applicable, an application must enable security headers and cookie security attributes.	`PLATFORM PROVIDED` Do not use `unsafe-inline` or `unsafe-eval` directives in `script-src` when possible. This will make the policy ineffective against cross-site scripting vulnerabilities.
	10. 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 using Forge SQL must not build SQL statements by concatenating untrusted input and must use parameterized queries where possible to mitigate SQL injections and unauthorized data access.
		2. An application must not execute arbitrary code by spawning child processes (for example, using Node.js `child_process` APIs or shell commands) and must securely sandbox any code execution to prevent unrestricted access to the app runtime.
	11. 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.
	12. An application must not use EOL (end-of-life) Node.js runtimes and unmaintained or deprecated libraries, especially those without upstream fixes.	There are no specific implementation details.
AI Security	13. An application using Forge Rovo actions must treat all action inputs as untrusted, except for context parameters. The application must validate `inputs` and verify permissions before executing sensitive actions or making network requests to mitigate prompt injection attacks and data exfiltration risks.	1. An application using Forge Rovo agents that can perform admin level actions must implement its own permission based checks so that only authorized users can invoke those actions, as Rovo agents are accessible to all users.
AI Security	14. An application using Forge Rovo actions must configure `actionVerb` values that accurately reflect whether an action only reads data or also performs mutable actions to preserve user consent and control over actions.	There are no specific implementation details.
Privacy	15. An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens. If an app needs to request or store Atlassian API tokens in order to access a REST API that does not currently support authentication from apps, the app developer can request Atlassian to make the changes to our API to support authenticated requests from apps. This requirement does not prohibit apps from storing credentials used to access non-Atlassian applications. For more details, read our FAQ.	There are no specific implementation details.
Vulnerability Management	16. 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.
	17. 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.
	18. 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.
		2. Before making calls using `asApp()`, you must verify the expected permissions (for example, from product context) with the permissions REST APIs.
		3. External OAuth2 clients used by an application must use Forge's OAuth2 Providers unless a required capability is not supported, and must be configured as confidential clients (requiring a `client_secret` to obtain or refresh access tokens) whenever the external OAuth2 provider supports both public and confidential client types for the relevant OAuth2 flows.
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
	6. Any Atlassian End User Data written to application logs must exclude Personally Identifiable Information (PII), credentials, and sensitive data.	There are no specific implementation details.
	7. An application must ensure strict tenant isolation during runtime. Data or variables from one tenant must not be accessible to another, including via runtime artifacts.	The boundaries of tenant safety and data handling are defined in the Shared responsibility model.
Application Security	8. An application must maintain and securely configure domains where the application is hosted.	This requirement does not apply to this app type.
	9. When applicable, an application must enable security headers and cookie security attributes.	`PLATFORM PROVIDED` Do not use `unsafe-inline` or `unsafe-eval` directives in `script-src` when possible. This will make the policy ineffective against cross-site scripting vulnerabilities.
	10. 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 using Forge SQL must not build SQL statements by concatenating untrusted input and must use parameterized queries where possible to mitigate SQL injections and unauthorized data access.
		2. An application must not execute arbitrary code by spawning child processes (for example, using Node.js `child_process` APIs or shell commands) and must securely sandbox any code execution to prevent unrestricted access to the app runtime.
	11. 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.
	12. An application must not use EOL (end-of-life) Node.js runtimes and unmaintained or deprecated libraries, especially those without upstream fixes.	There are no specific implementation details.
AI Security	13. An application using Forge Rovo actions must treat all action inputs as untrusted, except for context parameters. The application must validate `inputs` and verify permissions before executing sensitive actions or making network requests to mitigate prompt injection attacks and data exfiltration risks.	1. An application using Forge Rovo agents that can perform admin level actions must implement its own permission based checks so that only authorized users can invoke those actions, as Rovo agents are accessible to all users.
AI Security	14. An application using Forge Rovo actions must configure `actionVerb` values that accurately reflect whether an action only reads data or also performs mutable actions to preserve user consent and control over actions.	There are no specific implementation details.
Privacy	15. An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens. If an app needs to request or store Atlassian API tokens in order to access a REST API that does not currently support authentication from apps, the app developer can request Atlassian to make the changes to our API to support authenticated requests from apps. This requirement does not prohibit apps from storing credentials used to access non-Atlassian applications. For more details, read our FAQ.	There are no specific implementation details.
Vulnerability Management	16. 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.
	17. 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.
	18. 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 needs to request or store Atlassian API tokens in order to access a REST API that does not currently support authentication from apps, the app developer can request Atlassian to make the changes to our API to support authenticated requests from apps. This requirement does not prohibit apps from storing credentials used to access non-Atlassian applications. For more details, read our FAQ.	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.

3LO (OAuth) apps

This table gives guidance specific to 3LO (OAuth 2.0) (also known as "three-legged OAuth" or "authorization code grants") apps.

TYPE OF REQUIREMENT	SECURITY REQUIREMENT	IMPLEMENTATION DETAILS
Data Protection	1. An application must securely store and manage OAuth secrets, including client secrets, access tokens, and refresh tokens. These OAuth secrets must be stored encrypted and must not be made available in easily accessible locations, such as source code and application logs.	There are no specific implementation details.
	2. 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.	There are no specific implementation details.
	3. An application must adhere to the principle of least privilege by ensuring that the app's scope is limited to only the permissions necessary for its functionality.	There are no specific implementation details.
	4. An application must securely store customer data by implementing full-disk encryption at rest. Access to this data should be restricted on an as-needed basis, employing strong authentication and authorization mechanisms to ensure that only authorized personnel can access the data. Additionally, ensure that tenant isolation is enforced through logical separation and each customer's data is kept distinct from others to prevent data leakage.	There are no specific implementation details.
Application Security	5. An application must always set unique state parameters and validate them to ensure the integrity of authorization and callback requests, and prevent replay attacks. It is recommended to associate state parameters with the user's session and ensure they are cryptographically strong to resist brute-force attacks.	There are no specific implementation details.
Privacy	6. An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens. If an app needs to request or store Atlassian API tokens in order to access a REST API that does not currently support authentication from apps, the app developer can request Atlassian to make the changes to our API to support authenticated requests from apps. This requirement does not prohibit apps from storing credentials used to access non-Atlassian applications. For more details, read our FAQ.	There are no specific implementation details.
Vulnerability Management	7. You must know, understand, and follow our Security Bug Fix Policy. Learn about Atlassian's Security Bug Fix Policy for Marketplace Apps.	There are no specific implementation details.
	8. You must notify Atlassian of all security incidents via ECOHELP. Learn how to handle a security incident.	There are no specific implementation details.
	9. You must identify at least one email as a security contact and have them create an account so that they are notified about app vulnerabilities via Atlassian Marketplace Security (AMS) tickets. Learn 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.

These security requirements were last revised on February 19, 2026. Refer to our changelog for more details.