At Atlassian, our goal is to create a high level of trust and security in the Atlassian Marketplace for our users. To increase security across the Marketplace, the requirements on this page are mandatory for all Marketplace cloud applications to adhere to the marketplace vendor agreement. You are responsible to review and update your apps to make sure that they are compliant. We also encourage you to follow our security guidelines and best practices, although they are not mandatory.
As the Atlassian Marketplace evolves, we may need to change these requirements. A minimum of 30 days' notice will be provided, allowing you to make any updates to meet the requirements. We will give a longer notice period wherever possible. It isn't our intention to place an onerous security burden on you or create any surprises. Rather, our goal is to partner with you to create a high level of trust and security in the Marketplace.
Please refer to enforcement procedure on how Atlassian plans to enforce these requirements. We have also provided additional information on these security requirements and a FAQ to answer common questions.
The application must use TLS to encrypt all of its traffic and:
The 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.
For the domains where your app descriptor file is hosted and the domains specified (as the baseURL or other URLs) in the app descriptor file:
Your DNS configuration for subdomains must point to services that are in use.
The application must authenticate and authorize all requests. Anonymous access to application endpoints and resources can be allowed in scenarios where it is needed.
Access to Atlassian End User Data (as defined in 8.4(a) in https://www.atlassian.com/licensing/marketplace/publisheragreement) stored by your application and services must be authenticated and authorized. This includes, but is not limited to data stored in:
A Connect application must not expose its sharedSecret where it can be easily accessed, including:
The application must not expose JWT tokens and Oauth tokens where they can be easily accessed including:
A Connect application using JWT for authentication must validate the JWT on the server-side.
The application must not collect Atlassian user credentials.
The application must set HttpOnly and Secure when sending Set-Cookie headers for session-related cookies.
The application must implement the Referrer-Policy header. The header must not be configured to no-referrer-when-downgrade or unsafe-url.
The application must validate the qsh to prevent URL tampering.
The application must not use versions of third-party libraries and dependencies with known vulnerabilities of high or critical severity.
All vulnerabilities reported to you by Atlassian must be fixed within these timeframes:
|Severity||CVSS Score||Timeframe for resolution|
|Critical||CVSS v3 >= 9.0||Must be fixed within 4 weeks of being reported and CVSS scored.|
|High||CVSS v3 >= 7.0||Must be fixed within 6 weeks of being reported and CVSS scored.|
|Medium||CVSS v3 >= 4.0||Must be fixed within 8 weeks of being reported and CVSS scored.|
|Low||CVSS v3 < 4.0||Must be fixed within 12 weeks of being reported and CVSS scored|
Extensions to the above mentioned timeframes are handled according to the enforcement procedure defined.