Help with security vulnerability in Forge app


I got a list of security vulnerabilities from The EcoScanner check 3 weeks ago on my Atlassian app.

They all said the same message, which is:

Vulnerability Description
The EcoScanner check, Custom-Check-Authorization-<unique id here>, for FSRT has reported the following issue:

Authorization bypass detected through handler.<methodName> in "/tmp/forge-app/src/index.js".

The check provided the following proof:

Unauthorized API call via asApp() found via handler.<methodName>

Mitigation Recommendation
The following resource was provided as a remediation recommendation:

Use the authorize API or manually authorize the user via the product REST APIs.

I got around to addressing those vulnerabilities this week.

My understanding was that I’m using asApp instead of asUser so I changed all of my calls to asUser.

For example, here’s an example of a call to the Jira REST API that I do in my Atlassian app. I replaced asApp to asUser.

const response = await api
            route(`/rest/api/3/search`), {
            method: "POST",
            headers: {
                accept: "application/json",
                "content-type": "application/json",
            body: JSON.stringify(data)

I pushed a version to development and staging to get a green light from the bot. It returned the same vulnerability check so I figured I would push my changes to production.

I pushed my changes to production but still go a response from the EcoScanner bot telling me the same message as above.

I’m stumped. I don’t know what to change.

I’ve looked at the Authorize API but my calls in the handler file named above are on reading boards, statuses, and doing JQL queries through the Jira REST API. The methods in the Authorize API do not allow me to do these kinds of checks.

Does any know how to fix this problem? What did I forget? Is my issue related to my manifest.yml file instead? Or is there an alternate solution I didn’t see?

Any help or guidance would be appreciated,



From my experience the bot is kind of lazy and the check is not successful immediately. I believe Atlassian does the final check by hand. You may add a comment in the AMS ticket and wait for an answer.



We have the same issue, did you come up with any solution for this?



1 Like

There is already another thread here Forge custom fields with authorize in Forge app - which permission to use

I am also waiting for comment from Atlassian, either here or in AMS ticket. I have no idea why they set SLA of a month and completely ignore here in the community as well as in the ticket.


Following @ppasler comment above, I got a reply directly in my ticket telling me the bot was lazy. The person who commented in my ticket didn’t seem too worried about my issue.


1 Like


Sorry about the delay. The scanner workflow currently runs daily, and it looks like your changes just missed the cutoff, which caused it to be run in the next batch. I agree that this can be confusing, because there could be a 24+ hour delay in the time that someone pushes a patch and the next scan job is run. As such, we’ll be increasing the cadence of our scanner workflow from now on, so that there’s less of a delay.

Also, note that we only scan artifacts that were deployed to the production environment. We apologize as we should have indicated this in the ticket description. We’ll be updating the ticket descriptions of our Forge scanners to clarify that only production app code is scanned.

As always, feel free to request an extension if you need additional time on the ticket.



Thank you so much for such a great answer :grinning:

Hi @JoshuaWong thanks for joining the thread.

I am not sure if I understood it. Can we assume this security ticket as false flag? We have another similar thread Forge custom fields with authorize in Forge app - which permission to use

Hi @JoshuaWong
We have the same security vulnerabilities issue raised by the ecoscanner in our case we are using these endpoints where jira permissions are not required for the Forge app that created the custom field . we are unable to use asUser as by default jira user don’t have access to it.
should we assume that is a false positive?

Yeah we actually ran into this issue with a couple of other apps. The issue isn’t really with that endpoint itself, but that the invoking user may not have permission to view the underlying custom field(i.e. the custom field is only used in projects that the user does not have permission to view). One solution would be to make a call to with asUser to get the list of fields that the invoking user has permission to access and check if the supplied custom field is accessible to the user before making the other API calls.

I’ll ask around to see if there are any other ways to do this. Also, I’d like to emphasize that our main goal with these tickets is to work with Marketplace partners in resolving common security issues that can occur in apps. As such, if you had questions on your ticket that we were unable to get to for awhile or if you believe a patch would take longer than the provided SLA, please ask for an extension if you need one. It is our responsibility to ensure that partners have enough information needed to resolve these issues.

Thank you Joshua for replying to the community.

Unfortunately how these issues have been handled is yet another reason why I’m concerned that Atlassian isn’t ready to operate a platform with commercial apps. Can we get a proper SlE on the responses from Atlassian? I would expect it to be within 24 hours.

The excuse of “the scanner is lazy” or “the cronjob was broken” doesn’t really seem to fit for an enterprise security scanning solution imho. Once we push the fix - we need a signal back from the Atlassian asap or we have to assume that our fix is not valid.


1 Like

Would this scanner flag every permission violation, even if intentional?

Because when I want to set entity properties on a project, I know the user is not authorized to do this unless he is the project admin. But if my app only sets a particular entity property, I don’t think it presents a security risk or should be flagged.

Thanks a lot. I can confirm that it is working, and the bot is accepting the patching solution.