If your app uses any of the affected endpoints, you’ll have to request a new permission scope from customer sites that use your app. ADMIN is the highest permission scope available.
Chat with us
If you have any concerns or feedback, comment in the section below. We’d love to hear how we can help you.
I don’t quite understood why the Update project endpoint requires Administer Jira global permissions to do things like change the project’s Description, Avatar, Project Lead etc etc (which are all part of the ‘project details’), yet the GUI allows someone with Project Administrator permissions to change any of that, as per the Edit a project’s details page.
The only thing that should require Administer Jira permissions is, understandably, changing a project’s key or category etc.
Why are Project Administrator permissions acceptable for altering a project’s details via the GUI, yet not acceptable via Connect or via Basic Auth sessions? Will the classic OAuth permissions also be changing from manage:jira-project to manage:jira-configuration as well?
Sounds like it’s time to consider splitting the endpoint into two:
One for editing project details and only needing Project Administrator permissions
One for editing the project key / category / others and needing Administer Jira permissions
I agree that it’s a bit strage to require Admin Score from a plugin to be able to change / edit the project.
In addition, can you confirm that the required scope for project properties does not change? Plugins often store project specific settings as project properties and it should be avoided to change the scope to admin
I agree with @sunnyape. It does not make sense to change the Connect scope for apps to diverge from the default Jira permissions.
If a project administrator can use the API it with Administer projects permission, so should the Connect app. If a Jira Administrator can use the API with rights global administrator rights, so should the Connect app.
If you really want more granular (& secure) controls, upgrade the Connect app user to a full blown user and allow Jira administrators to assign them access rights based on user account instead of scopes. Not saying I would be happy with this change, but at least it is consistent.
@BobLiou seriously, the only thing Atlassian is doing here is breaking the principle of least privilege for many apps. Instead of targeted permissions, you will now see a huge increase of apps requiring full ADMIN scope (that they actually do not need).
If the sharedSecret of that app becomes compromised, Atlassian will be responsible for the fact that suddenly the attacker can do whatever they want instead of having limited access.
You are actively making Connect less secure. Stop doing that.
I agree with Remie. I’ll just change the privileges of all apps using this to ADMIN. Also what happens to all those users that don’t upgrade to the ADMIN version, the app will just be broken. Is Atlassian planning to force people to upgrade to the version of the app that will work?
@BobLiou For such a significant change, it would also be nice to have a good explanation of why this is required. The only justification I could find is:
To improve security
That is rather generic. As others have already elaborated, this reasoning is debatable without understanding the real driver for this decision.
Hi Everyone, I’m a senior engineer on this team and I’m happy to provide some more details and context to this issue.
As some of you have rightly mentioned, there is a discrepancy between the level of permission the connect app requires and the level of permission that is required by a user calling the api directly. We are making this announcement to re-align these permission levels.
@tbinna I’m happy to provide specific details around this once the change has been made, but currently as this is a security fix we would like to avoid broadcasting the vector we are worried about being abused.
@sunnyape You are entirely correct to say that the update api could, and likely should be split up between actions that should require global admin privilege, and those that require just project admin privilege. We routinely audit our APIs and flag down those that need rework, albeit that process also goes through a prioritisation exercise compared to other work that we’ve needed to do. Currently this API was not scheduled for rework, hence we needed to quickly fix the security issue.
@remie and @paul we are aligning the app permission with the user permission. Sadly currently we do not directly use this API as part of Jira’s experience, which is why it hasn’t been split into different APIs requiring different permission levels based on the changes that it makes to the project.
@aradu / @BobLiou I implore you to reconsider these priorities, and if this is not within your power please tell me who I should contact to make that happen.
Because as mentioned before without the API endpoints that allow apps to make changes to projects using least privilege access rights, Atlassian is forcing app developers to make Jira instances less secure by having to request for ADMIN scope.
@aradu, I don’t know how detailed the Atlassian API logs are, but perhaps you can analyse them to see how many Connect apps have made requests to those API endpoints in the past 6-12 months and cross reference them with their scopes to get an understanding of the extend of privilege escalation this change is going to create?
If the app is not using the 7 affected API endpoints then there is no change required. The Connect scope for API endpoints that read/get projects are not affected.
@remie From our logging and initial analysis, there are 118 connect apps that call to these endpoints, and out of those there are only 2 that will be affected by the change as they call out to these endpoints and do not already have the ADMIN scope.