Last updated Jun 5, 2020

Rate this page:

Security requirements for cloud applications

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 Partner 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 security bug fix policy 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.

Security requirements for all Marketplace cloud applications

  1. The application must use TLS to encrypt all of its traffic and:

    • TLS version 1.2 (or higher) are required. TLS version 1.2 using AES 256 encryption or higher with SHA-256 MAC is recommended.
    • HSTS must be enabled with a minimum age of at least one year.
  2. 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.

  3. 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:

    • You must maintain control of these domains.
    • TLS certificates of these domains must be valid.
  4. Your DNS configuration for subdomains must point to services that are in use.

  5. The application must authenticate and authorize all requests. Anonymous access to application endpoints and resources can be allowed in scenarios where it is needed.

  6. Access to Atlassian End User Data (as defined in 8.4(a) in stored by your application and services must be authenticated and authorized. This includes, but is not limited to data stored in:

    • AWS S3 buckets.
    • application databases.
  7. A Connect application must not expose its sharedSecret where it can be easily accessed, including:

    • URL strings.
    • Referer headers.
    • public repositories, such as Bitbucket and Github.
    • client-side storage.
  8. The application must not expose JWT tokens and Oauth tokens where they can be easily accessed including:

    • Referer headers
    • Public repositories, such as Bitbucket and Github
  9. A Connect application using JWT for authentication must validate the JWT on the server-side.

  10. The application must not collect Atlassian user credentials.

  11. The application must set HttpOnly and Secure when sending Set-Cookie headers for session-related cookies.

  12. The 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.

  13. The application must validate the qsh to prevent URL tampering. For Cacheable app iframes as documented here, this requirement does not apply.

  14. The application must not use versions of third-party libraries and dependencies with known vulnerabilities of high or critical severity.

  15. All vulnerabilities reported to you by Atlassian must be fixed with the security bugfix SLAs for cloud apps as defined in the Security Bug Fix Policy.

Rate this page: