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.
The application must use TLS to encrypt all of its traffic and:
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:
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.
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:
1 2Strict-Transport-Security: max-age=31536000; includeSubDomains
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.
For each page that serves sensitive data, examine the request headers and make sure that Cache-Control header is configured as follows:
1 2HTTP/1.1: Cache-Control: no-cache, no-store
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 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:
myapp.herokuapp.commyapp.comapp.partner.com/connect-for-jira/ and app.partner.com/connect-for-confluence/
An invalid baseUrl would be:
raw.githubusercontent.com/myapp/s3.amazonaws.com/myapp/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.
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.
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).
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.
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.
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).
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:
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.
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.
A Connect application must not expose its sharedSecret where it can be easily accessed, including:
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:
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.
The application must not expose JWT tokens and Oauth tokens where they can be easily accessed including:
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.
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.
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.
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.
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.
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.
A vulnerability scanner, such as Qualys, Nexpose, or Burpsuite, can detect the absence of these flags.
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:
1 2GET /js/addon.js HTTP/1.1 Host: matt-test-host-js.ngrok.io 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: https://matt-test-connect2.ngrok.io/xss-testing?xdm_e=... snip ... &jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.<redacted>
Request for an asset with the Referrer-Policy Header set:
1 2GET /js/addon.js HTTP/1.1 Host: matt-test-host-js.ngrok.io 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: https://matt-test-connect2.ngrok.io
Note: The above example sets the referrer-policy as Referrer-Policy: origin, so the origin will always be returned in the referrer header.
Atlassian Connect Express
You can add this header to your app universally by adding the following code into your main app.js:
1 2// Set no-referrer header on all requests app.use(function(req, res, next) { res.setHeader("Referrer-Policy", "origin"); return next(); });
Atlassian-Connect-Spring-Boot
Ensure you are using version 2.0.7 or later within your pom.xml
1 2<atlassian-connect-spring-boot.version>2.0.7</atlassian-connect-spring-boot.version>
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:
originstrict-originno-referrerScan your site using https://securityheaders.com/ to determine whether you have the Referrer-Policy implemented.
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.
To test this make a request with a JWT token, modify the query string, and check that the request fails.
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:
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.
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.
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: