Last updated Sep 27, 2023

Additional information: Security requirements

This page provides additional information on the security requirements for cloud apps. For each requirement, we have provided information on the reasoning behind the requirement and, where possible, how a Marketplace Partner can test if their applications meet that requirement.

Security is an important element of app cloud trust. To learn more about meeting your customer's trust needs, visit Customer trust in cloud.

Transport layer security

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.

All HTTP traffic is unencrypted by default, making it susceptible to eavesdropping and tampering. In order to ensure the security of data in transit, your application must use the Transport Layer Security (TLS) protocol. TLS provides a number of security benefits, including:

  • Confidentiality - protection against an attacker reading the contents of the traffic.
  • Integrity - protection against an attacker modifying the traffic.
  • Replay prevention - protection against an attacker replaying requests against the server.
  • Authentication - allowing the client to verify that they are connected to the genuine server. Note: The identity of the client is not verified unless client certificates are used.

For a list of recommended ciphers , refer to Modern and Intermediate compatiblity cipher recommendations in Mozilla wiki

In addition, your application must implement the HTTP Strict Transport Security (HSTS) response header. HSTS ensures that a website can only be accessed using HTTPS and also prevents click through prompts on browsers.

How to test

There are several tools that enable you to validate your TLS configuration, including Qualys SSL Labs and SSLyze.

We recommend that you use TLS version 1.2 or above, as earlier versions of TLS and the SSL protocol have significant security vulnerabilities.

To verify that your application correctly implements HSTS, look for this response header:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Cache control

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.

Browsers can cache information to improve performance. While there are performance benefits to browser caching, it may store sensitive data that can be retrieved by examining the browser's cache or navigating back a page. Therefore, pages that contain sensitive data must have the Cache-Control header enabled with the values no-cache and no-store instead of private.

How to test

For each page that serves sensitive data, examine the request headers and make sure that Cache-Control header is configured as follows:

Cache-Control: no-cache, no-store

Validity of domain registration & TLS certificates

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.

Your app's domain is defined as the domain of the baseUrl in your app descriptor. This domain serves as the entrypoint for your app as well as the source for app descriptor updates for Atlassian. You must keep this domain up-to-date and not let it expire.

Your app cannot use a shared domain for your baseUrl unless all apps are owned by the same partner. A shared domain is defined as any domain where your app does not have a unique origin and is only unique via the path portion of the URL.

A valid baseUrl would be:

  • and
    • NOTE: This is allowed as the same partner owns both apps.

An invalid baseUrl would be:


When a domain expires, it can be claimed by an attacker who can then host a malicious app under that domain. However, users who have not reinstalled the app will continue to communicate with the old domain enabling the attacker to serve malicious content to users.

TLS certificates are issued by a trusted Certificate Authority and accepted by major browsers. When a TLS certificate expires, browsers will start warning and blocking the use of your application. An attacker will, however, be able to generate self-signed certificates for your domain and launch man-in-the-middle attacks against your application users.

How to test

Make sure that your domains supporting the application are valid and up to date by checking the “Domain expiration date” in your domain’s WHOIS records. Enable auto-renewal on your domains to avoid expiration, where possible.

Tools that validate your TLS configuration, including Qualys SSL Labs and SSLyze, provide information on the validity of TLS certificates. Ensure your TLS certificates are signed by a Certificate Authority trusted by the major browsers and they are valid. Enable auto-renewal of TLS certificates, where possible.

If you received a ticket for an expired domain in your app, you must either re-register the domain or update the app descriptor with a domain you control.

If neither of these actions are taken within the security SLAs, Atlassian will delist the app. Note that you will receive notifications regarding the delisting timelines on the same security ticket before the app is removed from the Marketplace. For more information on security SLAs and enforcement procedure, visit security bug fix policy. For information about our vulnerability management framework, see Vulnerability management for Marketplace apps.

Domain and subdomain takeover

Your DNS configuration for subdomains must point to services that are in use.

Subdomain takeover is a vulnerability that occurs when a domain or subdomain CNAME is pointing to a service (for example, GitHub pages or Heroku) that has been removed or deleted. This enables an attacker to serve content on the unused or dangling subdomain by setting up an account on the third-party service and claiming the subdomain.

Marketplace app domains are rarely exposed to users directly. However, a subdomain takeover vulnerability is an issue as it provides for the bypass of security policies and access controls. Also, there might be an implicit trust between the dangling subdomain and the application (for example, Javascript from the dangling subdomain).

How to test

Check your organization's DNS to make sure there are no dangling subdomains. You can also do a fingerprint scan on the services you’re using. There are commercial tools such, as Detectify, and open-source tools, such as subjack and tko-subs, that help identify subdomain takeovers.

Authentication and authorization of application resources

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

Authentication is the process of determining that a user is who they claim to be, while authorization ensures that a user is allowed to access certain data or perform a specific operation within an app. Lack of authentication and authorization in applications can lead to vulnerabilities such as information disclosure, privilege escalation, authentication bypass, and others.

How to test

Authentication and authorization vulnerabilities are not easily detected by automated scanners, so we recommend using manual techniques to find them.

To test for authentication, send a request to each of your application’s endpoints without having an established session. If the endpoint returns data that should be protected by an authentication mechanism or enables you to perform sensitive state-changing action, then your application is vulnerable.

Similarly, when checking for authorization flaws or missing access controls, perform a request attempting to access or modify one user’s data while authenticated as another user. Be sure to test this for accounts with similar roles (horizontal authorization) as well as across different roles, for example, a low-level user to admin (vertical authorization).

Authentication and authorization of stored data

In addition to making sure that proper controls are in place to protect application endpoints, it is important that data stored by the application is protected as well. Lack of proper authentication and access controls could result in the exfiltration of your data.

How to test

Testing will depend on how your data is stored. For example, if you are using S3 buckets, make sure you’ve configured the correct permissions and use a tool, such as S3Inspector, to check whether your buckets are public.

Secure Handling of the sharedSecret

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.

If your Connect app’s sharedSecret was exposed an attacker can impersonate your app, so proper security measures must be implemented to secure it. The sharedSecret should:

  1. Be encrypted with a dedicated encryption key, this can make re-encryption easier and also provide an audit trail in the case of services like AWS KMS.
  2. Be encrypted in addition to any database or filesystem level encryption used by your app. This minimizes the impact of app bugs (like SQL injection) from disclosing the secret.
  3. Only stored on the app server-side.
  4. Only be decrypted and used during the JWT generation or verification process.

How to test

A manual audit must be completed to identify where the sharedSecret is being used to ensure that it's not being leaked by unintended API endpoints or other functionality of your Connect app or infrastructure.

Secret handling

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

Exposing sensitive tokens such as JWTs, OAuth tokens, and client secrets in unintended places can lead to account takeovers and user impersonation attacks. These values must be stored securely and only used for their intended purpose.

How to test

A vulnerability scanner, such as Burpsuite, can help identify whether sensitive tokens are leaking to third-parties through the Referer header. There are also open-source tools, such as gitleaks, that can help identify whether source code repositories contain tokens. Consider implementing git-secrets or a similar tool in your development environment to prevent sensitive tokens being committed.

JWT validation

A Connect application using JWT for authentication must validate the JWT on the server-side.

If the JWT token is not validated correctly by the app server, an attacker could trick the server in to process a malicious JWT token and then steal information accessible to legitimate users.

Details on how to correctly validate a JWT token can be found in the Validating incoming requests section of the Authentication for Connect apps page.

How to test

Burpsuite, a vulnerability scanner, can track outgoing requests from the web browser. Then use the JSON Web Token Attacker plugin, from the BApp Store, to change fields such as Alg and Signature in the outgoing JWT token. Requests with a manipulated token should not be processed by the server, confirming that the server is validating the JWT token.

Collection of Atlassian credentials

The application must not collect Atlassian user credentials.

A connect app should not collect or ask for Atlassian user credentials. Connect apps should use the JWT-based authentication provided by the Connect framework.

How to test

A vulnerability scanner. such as Burpsuite can flag any Atlassian user credentials being transmitted or stored in plain text. A manual audit of the source code must also be completed to ensure that Atlassian user credentials are not collected or stored by the app.

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

HttpOnly is an optional Set-Cookie HTTP response header flag. If supported by the browser, using HttpOnly when generating a cookie mitigates the risk of a client-side script accessing the protected cookie. If a browser that supports HttpOnly detects a cookie containing HttpOnly, and client-side script code attempts to read the cookie, the browser returns an empty string. This causes the attack to fail, by preventing the malicious (usually XSS) code from sending the data to an attacker's website

The Secure attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This protects the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in plain text.


How to test

A vulnerability scanner, such as Qualys, Nexpose, or Burpsuite, can detect the absence of these flags.

Referrer Policy

The application must implement the Referrer-Policy header. The header must not be configured to no-referrer-when-downgrade or unsafe-url.

If the appropriate Referrer-Policy header is not set it can lead to sensitive tokens leaking in GET URLs, including the query string, to third-parties through the Referer header.

Here’s an example both with and without the header which shows the impact of this issue.

Request for an asset without a Referrer-Policy Header set:

GET /js/addon.js HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:76.0) Gecko/20100101 Firefox/76.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Referer: snip ... &jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.<redacted>

Request for an asset with the Referrer-Policy Header set:

GET /js/addon.js HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:76.0) Gecko/20100101 Firefox/76.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close

Note: The above example sets the referrer-policy as Referrer-Policy: origin, so the origin will always be returned in the referrer header.

How To Fix

Atlassian Connect Express

You can add this header to your app universally by adding the following code into your main app.js:

// Set no-referrer header on all requests
app.use(function(req, res, next) {
    res.setHeader("Referrer-Policy", "origin");
    return next();


Ensure you are using version 2.0.7 or later within your pom.xml


Other Frameworks

If you are not using either of the above frameworks, you should ensure that the Referrer-Policy header is set in all of your responses.

The recommended directives are:

  • origin
  • strict-origin
  • no-referrer

How to test

Scan your site using to determine whether you have the Referrer-Policy implemented.

URL tampering

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

qsh is a custom Atlassian claim that prevents URL tampering by taking a SHA-256 hash of the original request's HTTP method, resource URI, and query string. By calculating the qsh in your application for requests received and comparing that to the qsh sent in the validated signed JWT token, you can guarantee that the URL has not been tampered with.


How to test

To test this make a request with a JWT token, modify the query string, and check that the request fails.

Use of external components

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

When using third-party libraries or dependencies in your application, you may be at risk due to vulnerabilities in those components. While some vulnerabilities reported in the third-party libraries may not affect your application, there are several reasons for this requirement:

  • Even if your application cannot be exploited directly, using an external component that is vulnerable increases the risk of a vulnerability arising in the future if the application changes.
  • This is an issue with Atlassian cloud products that our customers report most.

How to test

Use scanners, such as retire.js or OWASP dependency check, or third-party tools, such as Snyk or sourceclear, to detect vulnerable or deprecated components. We recommend that you use the latest stable version of any library to minimize the risk of exploitation.

Security SLAs

Vulnerabilities reported to you by Atlassian must be fixed within the defined security SLA timeframes.

Atlassian makes it a priority to ensure that customers' data cannot be compromised by exploiting vulnerabilities in Marketplace apps. We track security vulnerabilities in the Atlassian Marketplace Security project and continuously monitor for security SLA violations.

See the Security Bug Fix Policy for more information.

How to test

We provide you information on SLA due date and upcoming SLA violation through DEVHELP tickets. To achieve this requirement, ensure that you are aware of all vulnerabilities reported to your services.

Rate this page: