Feedback Request: Security Requirements for Cloud Apps

Just a bit nitpick here - but why is #10 (" An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens.") under Privacy? Especially since the linked document doesn’t talk about user credentials.

For the Forge scopes - I’m a bit confused. The granular scopes is on hold according to Action required: Update scopes for Forge and OAuth 2.0 (3LO) apps - should those sections be removed?

1 Like

Done!

  1. An 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.

This once more time brings up the question what should we do about Atlaskit libraries that are essential to the apps and are too complex to DIY for vendors, but Atlassian refuses to officially support, eg editor and jql-editor libraries. They have a “high” vulnerability in the dependency tree for over a year now, due to outdated styled-components library dependency.

UPD: moreover, this raises the question whether Atlassian is willing to adhere to the same rules. Because these libraries are widely used in the products (Jira and Confluence for sure)

10 Likes

Hi @clouless, thank you! It depends on what the “custom permissions” are trying to achieve really. We do not recommend attempting to build an “offline copy” of the product permission model in your app, as it would quickly become out of date from the permissions enforced in the products. However, If all user permissions are explicitly checked (mind you to be conscious about the possible permissions changes on the product) when using asApp() to restrict any elevated access, it will be inline with the intent of the requirement. Happy to assist you and discuss more of your use case - you can raise a ticket here.

1 Like

Hi @marc, both Connect & Forge apps are prohibited from requesting Atlassian API tokens from users and are not allowed to store them or use them in any way per the updated security requirements for Marketplace cloud apps. Apps should only authenticate with Atlassian products by using approved authentication methods such as JWT authentication (for Connect) or Product Fetch API (for Forge).

When apps utilize authentication methods like Atlassian API tokens and user credentials, it undermines several of the trust and security controls that we have in place to protect customers and partners. For instance, if a Marketplace app is compromised and an attacker obtains access to an Atlassian API token belonging to a user that is being stored by that app, it is extremely difficult for Atlassian to identify that the attacker’s REST API activity is originating from a specific app instead of from a specific customer. If the app was using an approved authentication method instead, Atlassian could identify the anomalous activity and take action to notify both the affected customer and the partner about the possible compromise possibly reducing the impact significantly.

Some partners have already indicated that they require Atlassian API tokens to access specific product REST APIs that do not currently support app authentication. Apps that are currently utilizing Atlassian API tokens for this purpose who report the situation to Atlassian will be granted a waiver on this specific requirement while we escalate with the appropriate engineering teams to add support for app authentication to these APIs. We are happy to assist you and discuss more of your use case, you can raise a ticket here.

Hi @danielwester,

This would let us explain to customer why other application types (such as standalone apps using oAuth).

Sure, we will link supporting documentation on the DAC page.

Just a bit nitpick here - but why is #10 (" An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens.") under Privacy? Especially since the linked document doesn’t talk about user credentials.

It was added under Privacy due to its impact on unintended access to cross-product (Jira/Confluence/JSM) data. Atlassian API keys are not scoped and allow similar access to product REST APIs that user credentials provide. The link was provided as a reference to general privacy guidelines.

For the Forge scopes - I’m a bit confused. The granular scopes is on hold according to Action required: Update scopes for Forge and OAuth 2.0 (3LO) apps - should those sections be removed?

I understand and apologize for the confusion on this topic in general. Our intent for this requirement is to make sure apps are not asking more than what they need, regardless of what’s made available to them by Atlassian. So when an app just needs read access, it must not ask for write access. Though Forge granular scopes are paused for now, the original intent remains the same i.e. do not ask for scopes that are not needed for its functionality. The timing here is really unfortunate with granular scopes being paused and the security requirements talking about the scope - but the objective holistically is about requesting only required scopes.

Hi @kazimir_io ,

This once more time brings up the question what should we do about Atlaskit libraries that are essential to the apps and are too complex to DIY for vendors, but Atlassian refuses to officially support, eg editor and jql-editor libraries. They have a “high” vulnerability in the dependency tree for over a year now, due to outdated styled-components library dependency.

NPM packages published under the Atlaskit scope are officially maintained and supported by Atlassian. We scan Atlaskit packages (and other Atlassian Frontend packages published to NPM under Atlaskit scope) for vulnerable versions of 3rd party libraries and dependencies on daily basis. We track these vulnerabilities and address them as per our internal priority scores. We are interested in knowing the unpatched “high” severity vulnerability you mentioned and we are happy to address it if you can raise a support ticket with us and provide more details on your finding.

Well the issue is that when we tell customers that we follow Atlassian security guidelines - they go “awesome” and then dig into it during their procurement process. When the guidelines then conflict with reality (as in this case) - we then end up having to tell the customers that Atlassian doesn’t really know what’s going on with their own programs…

Ideally you would leave this off until the rest of Atlassian can support your effort and then add it in.

Ohh ohh - I know this one. styled-components. Atlassian editor (for example) requires styled-components from X years ago - there is no eta on when it will be fixed.

We can also just go along with anything that reads adf and how it’s not compatible with new versions of react (which is just a matter of time before it becomes a problem).

1 Like

That sounds like an Atlassian issue - why aren’t Atlassian API keys scoped properly? When will Atlassian security require them to be scoped properly? (I would love for this to happen so that I don’t have to worry about Forge using them).

3 Likes

@SrivathsavGandrathi
While not strictly a dependency, atlassian-connect-express-template is full of security issues. This is the starter template for the ACE tutorials.

1 Like

Can you please design an approved way to render ADF content? Your rule against unsafe-inline CSPs prevents us from rendering ADF content.

  • We need to display excerpts of a Confluence page,
  • For example, we need to display a preview of the Confluence page, where we highlight the part (table cell, headers, images…) which we will change, so we need to interact with the rendering.
  • Another example is that we extract “requirements” from Confluence tables and display them in all sorts of places, so we need a safe way to render them,
  • It means we render ADF in a <div>, and apply the styles for the macros, and therefore we need to use inline styles. Maybe you’ll make an <adf content={adf} in-the-context-of={pageId} /> React component :wink: ? (But we group all ADF and perform a render request to Atlassian once for the whole page).

If Atlassian designs a safe way to do this, for example with a predefined CSS that covers all the built-in static macros, we’d be happy to use it.

2 Likes

We also use API tokens for user access of rest services not available in connect. It’s got super old years ago trying to raise these API deficiencies with Atlassian. If this is a to actually get your API’s usable so that such tokens are not required, that’s fantastic. Less fantastic is if we have to repeatedly justify the same workarounds to ‘new’ staff every time the ‘temporary’ approval lapses. Can you retain the explanations to limit repeat effort? Even better, can ‘temporary’ mean permanent until Atlassian actually address the root cause of lacking API’s … Otherwise its just tedious make-work…

Question on connect authentication:
Currently you can build and distribute an app with no authentication, i.e. a completely static app. This is described in https://developer.atlassian.com/cloud/confluence/connect-app-descriptor/ with authentication: {type: none}.
The new security requirements seem to imply that you must use authentication: {type: jwt} and validate the install lifecycle request.
This in turn would mean that purely static connect apps are not allowed anymore.
What is the Atlassian position on this?

2 Likes

@danielwester We will remove references to granular scopes for now but the overall intent of apps requesting minimal available scopes remains the same. FYI, we are in initial stages of addressing Atlassian account API token management.

@marc Thank you for informing, please note that configuration in templates may refer to development environment. We are happy to look into if you can share high impact issues noticed in atlassian-connect-express-template via a support ticket.
we are also aware of authentication: {type: none} use case and added a waiver for anonymous access in the Authentication & Authorization requirement. In order to avoid further confusion, we will also include below waiver to Connect specific section.

Only set authentication type to None in the app descriptor if all of the endpoints in descriptor serve only static content or do not include dynamic application data in their response.

@aragot For this specific feedback we are happy to connect you to right team and see if there are alternatives if you can raise a support ticket with us.

@AndyD Understood, we will document this waiver so that you do not have to explain until the waiver is addressed.

1 Like

I have a question about Content Security Policy (CSP) header from requirement 7.1
Do you have any acceptance criteria for CSP (set of required Fetch directives except script-src)? Maybe you could provide a recommended way to assess the strength of a CSP (for example all green marks in https://csp-evaluator.withgoogle.com)?

1 Like

Question about third-party libraries and dependencies with known critical or high vulnerabilities from requirement 9.

In some cases, third-party libraries and dependencies with known critical or high vulnerabilities do not affect an app. Sometimes it is not possible to update such dependencies asap because the fix is not available yet. Could you please recommend what should we do in such cases?

1 Like

I have a question about Content Security Policy (CSP) header from requirement 7.1

@dzagorovsky we wanted to let our developer community start implementing Content Security Policy (CSP) to mitigate most script injection-related vulnerabilities. The recommendation would be to start by specifying the script sources and not using unsafe-inline or unsafe-eval directives. This should give the minimum protection CSP offers. https://csp-evaluator.withgoogle.com/ can be used to validate your policies.

Question about third-party libraries and dependencies with known critical or high vulnerabilities from requirement 9.

We recommend avoiding the usage of libraries or dependencies with critical or high severity vulnerabilities and instead use a patched version of these dependencies. If available, use an alternative library/dependency that is free from high/critical severity vulnerabilities. In case, neither is possible, we suggest you evaluate the risk and exploitability of the vulnerability and apply any known workarounds. However, when there is a zero-day vulnerability identified (e.g. Spring4Shell) on a library that significantly impacts customer data, we will file an AMS ticket, and developers are expected to resolve them within the due date specified on the ticket.

Now that draft requirements have become published, I’m locking this thread. All feedback and questions are still welcome, please just post them as new topics.

1 Like