One major concern we heard was around timelines - partners requested more time to fulfill the requirements than we had originally proposed. We’ve extended the date to bring apps into compliance, and partners now have until October 31, 2022 to meet the new requirements.
We’ve shared more background and detail about these updates on the developer blog. If you have questions, we’ve published a new FAQ page, and you can also ask questions in this thread.
Review this document for specific updates - security-requirements-status.pdf (111.7 KB)
With regards to point 6, we have a few apps whose baseUrls point directly to AWS services, like Cloudfront or API Gateway. Would this still fulfill the requirement, or would it be necessary to change these baseUrls to point to a separate domain name that belongs to us?
Hi @boris we added the New tag to feedback PDF for review but haven’t included it in the actual page since it is not relevant for published requirements. New Tags in this PDF are still correct and can be used to find the updates. Sorry if it caused confusion.
@stephendeutsch1 Intent of the requirement is to maintain control of domain to ensure that domain is not expired and TLS certificates are valid, etc (Please see Implementation details for platform-specific requirements). It is not required to change the baseUrl as long as the domain is unique and controlled by you.
@SrivathsavGandrathi would it be possible to start soft enforcement of these requirements through the Atlassian EcoScanner in either September or early October? That way, vendors will be notified of possible issues prior to the requirements going into effect and fully enforced.
It is relevant to published requirements. You need a change log. A change log needs to call out what is new, and what changed. It’s disrespectful of thousands of vendors time to ask us to manually recheck every single requirement whenever an update is made.
would it be possible to start soft enforcement of these requirements through the Atlassian EcoScanner in either September or early October? That way, vendors will be notified of possible issues prior to the requirements going into effect and fully enforced.
@remie / @clement_garin While we are planning on adding more validation in near future, building towards our ultimate goal of validating that each security requirement is met by an app, we do not yet have a solid roll out date for new Ecoscanner checks. We will make sure to communicate timelines as they get decided to give enough prior notice. We will also plan on adding the new checks to Connect Security Requirements Tester arsenal.
Obviously we don’t own amazonaws.com, but if we are fully in control of the subdomain, that is enough to meet the requirements?
@stephendeutsch1 It is understandable and control on subdomain also meets the requirement.
It is relevant to published requirements. You need a change log. A change log needs to call out what is new, and what changed. It’s disrespectful of thousands of vendors time to ask us to manually recheck every single requirement whenever an update is made.
@boris We infact published the changelog here, https://developer.atlassian.com/platform/marketplace/changelog/#CHANGE-663 . I went ahead and updated the changelog to include specific updates document upon your suggestion which is now attached in this post. We will make sure to post these specific updates to changelog moving forward where partners can find the changes easily and also link it in actual page. Thank you for your feedback.
Hi @SrivathsavGandrathi ,
We are working on getting our apps in compliance with the new security requirements. However we came across the following:
In essence, it seems using AUI is not in compliance with the security requirements. However it is an official Atlassian supported UI library, and we are using it in our apps.
What is the stance of the security team on this?
Hi @marc ,
I see that latest AUI is on 9.x version. While usage of eval in AUI has been addressed in the past, I have reached out internally to address any other usages. Please feel free to log any AUI security-bugs here. Meanwhile, for short term mitigation, please sandbox the code processed by eval() function.
Before making calls using asApp(), you must verify the expected permissions (for example, from product context) with the permissions REST APIs.
Does it mean that Atlassians expect there are always 2 APIs for every API call now? What is the purpose of making REST API calls from within a Forge app to validate that the app has permissions to make an API call?
Sorry for the delay, the purpose of this validation step is not to verify if the app itself has permission to make the call, it’s to verify if the invoking user has permission to make the API call. Since any user on the cloud site can manually invoke Forge app functions, there will be instances where the Forge app has more scopes than the invoking user leading to privilege escalation scenarios. Please read https://developer.atlassian.com/platform/forge/shared-responsibility-model/#authorization-of-requests-to-the-app for more information. Thanks!