Last updated Sep 27, 2023

FAQ: Security requirements for cloud apps

Find our responses and resources to address common security questions.

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


What are the security requirements for cloud apps?

The security requirements for cloud apps are a combination of security best practices and app security defenses that prevent security vulnerabilities from being introduced in apps.

Why do you have security requirements?

Our goal is to create a high level of trust and security in the Marketplace for our users. We use the requirements as the first step to improve security in Marketplace apps. It isn't our intention to place onerous security burdens on Marketplace Partners or create any surprises. Instead, we want to work with Marketplace Partners and provide the resources necessary to achieve these mutually beneficial security goals.

How were these security requirements chosen?

The list of requirements reflects common security issues affecting Marketplace cloud apps. These are verifiable defenses, which we can validate manually or automatically.

How often do you update these security requirements?

We intend to update security requirements annually in April to make sure our policies reflect the latest vulnerabilities, technology changes, and customer needs. The updated requirements will be effective by the end of October in order to give partners and developers enough time to make changes.

What happens if I don't meet these security requirements?

When we detect that an app isn't meeting a security requirement, we create a vulnerability ticket in our vulnerability management system, Atlassian Marketplace Security (AMS). From there, we track your progress in addressing the vulnerability, and provide support when needed.

Which apps do these requirements apply to?

These requirements currently apply to Connect apps, Forge apps, Forge apps that egress data, and Trello apps (Power-Ups).

What's the difference between the requirements and guidelines?

The security requirements are mandatory defenses that apps must implement. The security guidelines are non-mandatory recommendations to improve the security of your app.

Are the requirements mandatory for free apps?

Yes. All cloud apps must meet the security requirements, including free apps.

How do I make sure my app meets these requirements?

You can use open-source tools to check if your app meets the requirements. Please read our additional Information for advice on how to check whether your app is compliant.

My app doesn't meet a requirement, but I have a workaround. Will I be penalized?

If the workaround mitigates the security vulnerability, then you won't be penalized. The Atlassian security team will evaluate this on a case-by-case basis. To learn more about the process, see security bug fix policy.

How can I provide feedback about the requirements?

If you have any questions or feedback about the security requirements, please use the "Give docs feedback" provided above.

App listings

How does this impact the listing process?

The requirements don't impact the listing process. Apps won't be tested before listing, but are subject to continuous review by the Atlassian security team. Any security gaps identified will be addressed by following the security bug fix policy.

Are apps permanently de-listed for not meeting the security requirements?

No. Once the security requirements are met, the app can be relisted on the Marketplace.

Data, authentication, and encryption

How do I encrypt data at rest?

You are responsible for ensuring encryption of data at rest for any data that is not stored in the Atlassian infrastructure.

This includes Forge apps that egress data to external data stores. Data storage is covered in our Forge shared responsibility model. At a minimum, we require you to enable full disk encryption (FDE) (disk level) on your server to ensure at-rest encryption is enabled for End User Data stored outside of the Atlassian product or user’s browser, and they have some level of protection. If the data is stored in managed services like S3, this requirement asks you to enable at least the default encryptions offered by any managed service. The encryption requirement is met for any data stored inside the Atlassian product (e.g. entity/content properties).

Does Atlassian have role-based access controls of least privilege?

Forge has role-based access controls as seen in our Security Practices trust centre. However, we don't provide or enforce role-based access controls for partners building Forge apps.

Does the authentication requirement mean I can't use anonymous access in Connect apps?

No. If an app’s authentication type is set to none in the app descriptor, and if all endpoints serve only static content, then this requirement doesn't apply.

Yes. Apps cannot collect or store credentials belonging to Atlassian user accounts, such as user passwords or user API tokens.

When apps use Atlassian API tokens, it undermines several of the trust and security controls that Atlassian has in place to protect customers and partners. For example, in case of an account compromise, it's extremely difficult for us to identify that the REST API activity is originating from a specific app instead of from a specific customer.

If a product REST API doesn't support JWT authentication, you can contact us. We'll work to add JWT authentication, and won't create a vulnerability ticket in this case.

If I store data about a data subject, can you process/access requests from them?

You will have access to UGC/Personally Identifiable Information (PII), which is controlled and declared through scopes and permissions in the Forge manifest/Connect descriptor. However, you are still responsible for cleaning up anything that is stored outside of the Atlassian systems from these responses.

If I store data about a data subject, can you process erasure requests from them?

If you poll us at least every 7 days, you should be able to process deleted accounts within the timeframes required by GDPR (2-4 weeks). For more information, see our user privacy guide for developers.

Rate this page: