This page provides additional information on the Security Requirements for marketplace cloud apps. For each requirement, we have provided information on the reasoning behind the requirement and, where possible, how a Marketplace vendor can test if their applications meet that requirement.
The Security requirements and the supporting documentation is planned to take into effect as of January 1, 2020
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.
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:
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:
1
2
HTTP/1.1:
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.
The domain where your app is hosted as specified in the app descriptor file (atlassian-connect.json). The domain where your app descriptor file is hosted serves as the source for app descriptor updates for Atlassian.
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.
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 marketplace 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).
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](https://github.com/kromtech/s3-inspector), 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 be encrypted and stored on the app server-side and only used during the JWT 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](https://portswigger.net/), can help identify whether sensitive tokens are leaking to third-parties through the Referer header.
There are also open-source tools, such as [gitleaks](https://github.com/zricethezav/gitleaks), that can help identify whether source code repositories contain tokens. Consider implementing [git-secrets](https://github.com/awslabs/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](https://portswigger.net/) 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.
Session cookie configuration
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 mitigate 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.
Referer 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.
#### How to test
Scan your site using https://securityheaders.com/ to determine whether you have the Referrer-Policy implemented.
URL tampering
The application must validate the qsh to prevent URL tampering.
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.
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](https://retirejs.github.io/retire.js/) or [OWASP dependency check](https://www.owasp.org/index.php/OWASP_Dependency_Check), or third-party tools, such as [Snyk](https://snyk.io/) or [sourceclear](https://www.sourceclear.com/), 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 Atlassian products. This requirement extends that behavior to Marketplace cloud applications. As Atlassian cannot have visibility on all your security vulnerabilities, we monitor for security SLA adherence and violations on vulnerabilities that we have reported to you through an app security incident ticket (DEVHELP) and the vulnerabilities that get reported to you through the Marketplace bug bounty program.
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.