How can I secure my confluence app’s install endpoint from calls that do not genuinely originate from Atlassian?
My understanding is that on first install of an app there is no JWT token because there was no previous shared secret between the connect app and Atlassian for that customer’s install. See security for connect apps.
Since confluence apps must persist the clientKey and sharedSecret on app install my concern is that anyone on the internet can post to my install endpoint and I’ll end up persisting junk data in my database. I’ve obfuscated my install url but it’s easy to discover by reading my app’s descriptor atlassian-connect.json. As far as I know the filename for the app descriptor can’t be obfuscated, is that correct?
Is there anything I can do to secure the install endpoint on first call so only genuine calls from Atlassian are accepeted? A few possible ideas spring to mind
- A shared secret between Atlassian and my developer account which can be used as an auth bearer token.
- IP address list of Atlassian hosts, I know this might be brittle
2 Likes
There isn’t anyway to lock it down. 
If it is really a concern you can always verify the instances after the installations by calling rest end points to make sure it’s a real instance…
But to be honest i have yet to see it become a real issue.
2 Likes
Thanks for prompt reply! I’ll give that a go.
We recently went through this thought experiment and realised for our usecase it is indeed a security risk.
We created a ticket with Atlassian Security and they were quite helpful (they also mentioned they plan to publicize the response, so perhaps there will be some documentation etc. at some point soon)
Basically there is no perfect approach but there are a few things you can / should do:
- make sure you are validating the install payload and that the baseURL is indeed a valid atlassian.net instance
- you can check the remote ip of the install request is from within the ranges published here:
ip-ranges.atlassian.com although it is not strictly guaranteed that the remote ip will come from this range, it would be very unusual if it was outside the ranges published there.
- you should make a callback to the baseurl to check the shared secret is valid for the instance as @danielwester mentioned. Be aware it is possible that in some cases this wont immediately succeed, so this probably needs to happen asynchronously from the original install.
- You can periodically check marketplace to ensure you dont have any rogue installs.
1 Like
These techniques really need to be implemented in the official connect app frameworks. Any word from Atlassian on whether or not that is planned? That would serve the dual purpose of supporting users of those frameworks and acting as a reference implementation for others.
3 Likes
ip-ranges.atlassian.com is more for the front end app though (I believe).
the baseURL can be other things than atlassian.net though (I think there are some old versions with .onjira.com or something?). It def can be different with the customizable url that’s coming down pike.
3 Likes
The ip ranges on that list were confirmed in our ticket with Atlassian to be the ip’s we should expect the install request from. Hopefully, they do document this somewhere more clearly, so others can be confident. In my testing all install requests have come from those ranges.
While I understand there are some older instances on domains that aren’t atlassian.net, my understanding was that custom domains will still still have an atlassian.net baseurl, and the “custom” part will be listed in the display url section? I could be wrong, as we are still relatively new to cloud development.