Last updated Aug 29, 2023

Rate this page:


Maintaining a secure Marketplace is a collective effort, shared by Atlassian and partners. Atlassian's Security Requirements for Cloud Apps reflect the most current best practices for building secure apps and provide platform-specific guidance. They set Atlassian's baseline standard for cloud app security, and are updated annually to ensure alignment with industry standards. This page outlines how Atlassian validates that apps are following security requirements via scanning.

The Ecoscanner platform is a platform used for performing security scanning against all Marketplace cloud apps on an ongoing basis. This will help us continuously monitor our Marketplace cloud apps for common security vulnerabilities and improve the overall security posture of our ecosystem.

What type of scans will the Ecoscanner Platform run?

Missing Security Requirements

In order to validate that apps are meeting security requirements, we continuously launch new security scanners to expand requirements coverage. Below are some of the security requirement checks that Ecoscanner platform performs as of today.

Security requirementEcoscanner checkCVSS scoreDetails and remediation
Connect 1.1An application must always use JWT as the authentication type to validate the application identity and the integrity of the request.5.3 (Medium)Authentication of Application Resources
Connect 1.2A JWT token must be validated on the server-side for every authenticated request. Validate all user permissions to ensure that only permitted users can execute actions within an application.8.8 (High)Authorization of Application Resources
Connect 1.4An application must always validate install/uninstall lifecycle requests.8.6 (High)Signed Install Authentication
Connect 3The application must use TLS to encrypt all of its traffic and TLS version 1.2 (or higher) are required.7.4 (High)Transport Layer Security
Connect 3HSTS must be enabled with a minimum age of at least one year.6.8 (Medium)Transport Layer Security
Connect 5.1An application must never store secrets or authorization information in Jira Entity properties / Confluence Entity Properties.7.5 (High)Insecure Storage of Secrets
Connect 6.1An application must maintain control of each domain.9.0 (Critical)Domain Security
Connect 6.2An application owner must maintain valid TLS certificates of the domains where an application is hosted, and the domain must be signed by a trusted Certificate Authority8.1 (High)Validity of Domain Registration & TLS Certificates
Connect 6.3An application’s DNS configuration for subdomains must reference services that are in use.9.0 (Critical)Subdomain Security
Connect 8.0An application must validate and sanitize all untrusted data and treat all user input as unsafe to mitigate injection-related vulnerabilities. Untrusted data is any input that can be manipulated to contain a web attack payload.7.1 (High)Input Validation (Cross-Site Scripting)
Forge 1An application must authenticate and authorize every request on all endpoints exposed.8.8 (High)Authentication and Authorization
Forge 5An application must securely store and manage secrets, which include OAuth tokens, Trello tokens, sharedSecret, API keys, and encryption keys. They cannot be stored in places that are easily accessible.7.2 (High)Secure Handling of Secrets
Forge 9An application must not use versions of third-party libraries and dependencies with known critical or high vulnerabilities. When vulnerabilities in these libraries and dependencies are discovered, an application owner must remediate them as quickly as possible.High / Critical
*This depends on the specific vulnerability
Open Source Security

We open sourced a handful of security requirement testing tools namingly,

These tools are built specifically to scan for missing security requirements on Connect and Forge apps respectively.

We scan and ticket Marketplace apps developed on Connect using CSRT, Forge apps using FSRT and CVS tools. While our goal is to validate each security requirement for every app, we currently scan for a subset of the security requirements due to the fact that not all security requirements can be scanned with 100% confidence.

We also use other internal scanners to validate security requirements apart from CSRT, CVS and FSRT tools. Below are those scans that we perform using internal only tools.

Connect Scans Apart From CSRT

1. Expired domains

Marketplace apps with a registered domain that is expired can be re-registered by a malicious user and then used to exfiltrate sensitive information from any tenant where the vulnerable app is installed.

How we scan for expired domains

We check the app baseUrl for domains that appear to be available for registration. For apps with expired domains, a security vulnerability ticket will be raised with the severity of Critical (9.0).


Domains for any app installed on a customer tenant must be owned and controlled by the developer of the app. Apps that are no longer maintained must be uninstalled from all customer instances.

2. Subdomain takeovers

Connect apps with an unclaimed subdomain can be taken over by a malicious user and then used to exfiltrate sensitive information from any tenant where the vulnerable app is installed.

For example, a Connect app’s baseUrl was or was CNAMEd to, and the app developers have not claimed that subdomain on heroku. An attacker can then create an app on heroku named vulnerable-app-name, and receive traffic that was meant for the vulnerable Connect app.

How we scan for subdomain takeovers

We take in a list of connect apps with their remote descriptor urls and check if their remote descriptor url and/or baseUrl are vulnerable to subdomain takeover. We use this repo with some additonal validation to check which subdomains we can take over. For apps that are vulnerable to subdomain takeover, a security vulnerability ticket will be raised with the severity of Critical (9.0).


Domains for any app installed on a customer tenant must be owned and controlled by the developer of the app. Apps that are no longer maintained must be uninstalled from all customer instances.

Forge Scans Apart From FSRT

1. Secrets in source code

Hardcoding secrets in source code can cause secrets to be leaked and also lead to malicious activities like account compromise and user impersonation attacks. Secrets must be stored and retrieved securely.

How we scan for secrets

We use our internal secret scanning solution built using open source secret detectors like trufflehog. Additinally, we validate detected secrets to avoid false positives. If a valid secret is found in Forge app source code, a security vulnerability ticket will be raised with the severity of High (7.2). Note: we will increase the severity accordingly incase secret is found to be publicly available.


Either manually audit your source code or consider implementing tools like trufflehog, git-secrets or similar tools in your development environment to prevent sensitive tokens being committed.

2. Third-party dependency vulnerabilities

Open source is powerful, and almost all developers in the world rely on open source libraries for their applications. But it's time to stop ignoring the security risks from these libraries now that recent past had many zero day vulnerabilities that arose from third party software. Libraries/dependencies with known critical or high severity vulnerabilities must be patched or upgraded as soon as possible to mitigate the imminent threat posed to customer data.

How we scan for third party dependency vulnerabilities

We use Snyk tool to scan for vulnerabilities in open source libraries used by the app. Security vulnerability tickets will be raised for all critical and high sverity findings. Note: We use Snyk Priority Scoring model for scoring vulnerabilities identified by the tool.


We recommend that you use the latest stable version of any library to minimize the risk of exploitation and immediately patch libraries when zero-day vulnerabilities are disclosed. Use scanners, such as Snyk or OWASP dependency check to detect vulnerable or deprecated components used in your application environment.

Scan Cadence

The Ecoscanner runs all Connect related checks daily and all Forge related checks when a new version of the app is released. Since XSS-Check scanner is long running scan, we run it monthly.


Apps that miss security requirements will receive AMS tickets that are subject to our timeframes for resolution outlined in our Security Bug Fix Policy.


Can we have the Ecoscanner scan only our staging environment?

All scanning activity originating from Ecoscanner is supposed to be non-intrusive and very basic so Atlassian will continue to scan the production environment of cloud apps for now. If this changes in the future, we will communicate accordingly.

How do we know if the scan traffic is coming from Atlassian and not from some adversary?

All scan traffic should originate from the below listed IPs and IP Ranges:


What would the scanning be like? How intrusive? Requests/sec? What kind of requests should we expect to see?

Generally speaking, the more links in your descriptor, the more traffic you will receive. The traffic is very “bursty”. But, some approximate numbers are below:

Initial validation – Max 2 requests

Descriptor scan – Max 6 requests per link

TLS scan – No noticeable traffic at the app-level

XSS Scanner – Unlike other non-intrusive scanners in our tool suite, Cross-Site Scripting scanner tries to fuzz the form parameters in the HTML Iframe of the app. Fuzzing can generate considerable amout of traffic and you might notice random XSS payloads in your application logs.

Apart from the CSRT, FSRT scanners, what other types of scanning will happen? Will they be announced and open sourced as well?

As and when we introduce additional scanners, we will follow up with a CDAC post and also update this page. It is important to note that we cannot open source each scanner that we use for Marketplace apps since we license some scanners ourselves; but we will open source everything that we can. We will treat open sourcing on a case by case basis.

Does scanners scan all versions of a Forge app?

Currently Forge scanners will automatically scan the latest version of each Forge app and validate security fixes on the latest available version.

Can we build our own scanner and ask Atlassian to run it for us and for other Marketplace apps?

Yes, absolutely. We would totally love this. You come up with scanners and let us deal with figuring out how to run them at scale against all apps. Please feel free to create a request in our service desk describing the scanner and instructions on how to run it.

What will be the cadence of the scanning? What time/time zone will the scanning occur?

We will keep the scanner sections above updated with their scanning cadence

How will we get notified about the scan results?

All vulnerabilities identified from the scans will be reported via the AMS project in

Will server/DC apps also get scanned?

As of now, we are not planning to scan server and DC apps. This might change in the future as the Ecoscanner platform becomes more mature.

Can apps opt out of scanning?

Apps CANNOT opt out of scanning at this time.

How do we get in touch or contact Atlassian if the scanning somehow breaks the app? How do I get support wrt the scanning?

We hope this never happens since the scanning is going to be non-intrusive (unless otherwise mentioned). In the odd case when it does end up breaking your app and you want us to look into it, please go ahead and create a request on our service desk.

Why are we not scanning all the security requirements? Out of all the security requirements that will be scanned, which ones will be reported as security vulnerabilities?

We understand it is not practically possible to scan for all the requirements (because of the subjective nature of them that is different for different apps) but there are a handful of requirements that we can scan for. We are currently scanning these and reporting valid vulnerabilities identified via the AMS project. However, Atlassian is performing security tests to expand our coverage and validation of the security requirements by testing for requirements and common vulnerabilities that we currently do not scan for.

Rate this page: