This guide is designed for security researchers and penetration testers who are testing Atlassian Marketplace Cloud Apps. It provides links to official documentation, highlights common vulnerabilities, and offers resources to ensure you have the tools needed to test an Atlassian Marketplace app successfully. This is not meant to be a comprehensive testing guide, but rather a starting point for first-time Atlassian app testers.
This guide applies to all Atlassian Marketplace cloud apps, including those built on Forge and Connect.
Learn more about the Atlassian Marketplace platform in general. This document has a list of the security requirements sorted by framework and can be a good resource to understand what requirements app developers are aiming to meet when building apps.
Forge and Connect are Atlassian's two frameworks for building cloud apps in the Atlassian Marketplace. See the cloud development options comparison for the main differences between Forge and Connect. Connect apps are hosted on the app developer's server while Forge apps are hosted within Atlassian infrastructure with some permitted external hosts. It's helpful to understand the threat surface based on the type of app and its external hosts.
Check the app's Marketplace listing to determine its framework: if the listing provides a descriptor file (e.g., a publicly accessible Connect descriptor URL), it's a Connect app.
In practice you can look at the Cloud version of the marketplace.atlassian.com listing for the app and scroll down on the Overview tab to Resources. If there's a descriptor, it's a Connect app. Otherwise, it's a Forge app or Connect on Forge app.
To be accepted as a valid AMS ticket, certain conditions must be met, which are categorized under three main, industry wide accepted principles: verifiable, impactful, and exploitable.
The vulnerability must…
Verifiable: Have actionable reproduction steps or an applicable CVE - no speculative findings
Impactful: Have a non-zero CVSS score and have some impact on the Confidentiality, Integrity, and/or Availability of the application
Exploitable: Impact a cloud asset or a component that is shipped to customers
The vulnerability must meet all 3 of these criteria to be considered a valid AMS ticket.
Before testing an app for vulnerabilities, it's important to understand the app's architecture and gather relevant information about its implementation.
| PLATFORM | RESOURCES |
|---|---|
| 🔗 Connect | Getting started with Connect App Descriptor The app descriptor (with base URL) is accessible via the marketplace listing and can be used to identify the app domain for testing. |
| ⚡ Forge | Getting started with Forge Forge Manifests Forge utilizes manifests, a YAML file ( manifest.yml), that describes your Forge app. It includes the modules the app wants to use, the permissions it requires, and other configuration details about the app. This is not a publicly accessible file but reading up on it can give you an idea of what is configurable by the app developer. |
| VULNERABILITY AREAS | RESOURCES |
|---|---|
| Broken Authentication and Authorization Bypass Please refer to the documentation here to get a basic understanding of Authentication and Authorization in Marketplace apps: https://developer.atlassian.com/developer-guide/auth/ | 🔗 Connect Broken Authentication In Connect apps, JWTs (JSON Web Tokens) are used for authentication. They describe the user, the context (for example, a Jira issue or Confluence page), and the site the request was made from. JWTs can be decoded using an online JWT Decoding tool. Authorization Bypass For Connect apps, developers are recommended to have authorization in front of every endpoint exposed by the app, every interaction with an Atlassian API endpoint in response to a user request, and when the app leverages Atlassian app permissions. Considering the manual nature of these checks, it is important to test thoroughly. Read more here: https://developer.atlassian.com/developer-guide/connect-app-authorization |
| ⚡ Forge Broken Authentication In Forge, authentication is abstracted away from the developer using OAuth 2.0 Protocols. However, it is still important to check for unauthenticated webhooks and similar attack vectors. Authorization Bypass In Forge apps, usage of asApp() permission allows apps to access Atlassian APIs on an app's behalf, limiting the set of allowed actions by the permissions of the user. However, if not managed correctly, it can lead to unauthorized access to resources. This is an example of how requests are made from a Forge app: https://developer.atlassian.com/platform/forge/apis-reference/fetch-api-product.requestjira/ | |
| Input Validation Injection attacks in apps are mainly executed when an app does not validate/encode user data received from various sources. Most reported vulnerability in this area is XSS. However, for testing purposes, focus on all kinds of input forms for RCE, SQL, etc. | Connect & Forge Input Validation Cheat Sheet (OWASP) https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html Additional Documents: XSS Prevention in Marketplace apps |
| Broken Access Control Broken Access Control vulnerabilities arise when apps fail to implement access controls that do not allow users to act outside of their intended permissions. Cross Tenant Data Leakage The Atlassian cloud apps are multi-tenant, so apps need to be multi-tenant. However, this means that apps can potentially mix customer data. For example, two customers use an app that uses a global object to cache data by issue key. Issue keys are not globally unique, therefore data could leak from one customer to another. Please refer here for multitenancy concept in Atlassian cloud apps: https://developer.atlassian.com/developer-guide/multitenancy/#multitenancy | 🔗 Connect https://developer.atlassian.com/developer-guide/multitenancy/#multitenancy-in-connect |
| ⚡ Forge https://developer.atlassian.com/developer-guide/multitenancy/#multitenancy-in-forge |
Rate this page: