Deprecation of Connect JS getSelectedText API for security reasons

What is changing?

We are deprecating the AP.Host.getSelectedText API in Jira and Confluence, due to security and privacy concerns.

Why is it changing?

This API grants access to text the user has selected anywhere on the page, without any confirmation or intervention by the user. It is not clear when an app is installed that this behaviour is possible. This presents a security and privacy risk to the user.

What do I need to do?

If your app does use this API, there’s nothing you need to do to keep your app running without errors.
The deprecation will be handled in a backwards compatible manner, the API will simply return the empty string "" under all circumstances.

If your app relies on this functionality, please first consider whether there is another way to get the information you need, such as asking the user to copy/paste the selected text. This restores the user’s control over which data they want to share.

Another option is migrating to our new app platform, Forge. Forge has implemented this same API in a much more privacy-preserving manner, by requiring the user to select the text they wish to share and then explicitly choosing an application to process that selected text.
See this guide for an example: Use selected text in a Confluence Forge app

If migrating to Forge is not an option, other app developers have created a browser extension to workaround this limitation, as this API already doesn’t exist in Server editions of our products.

By when do I need to do it?

We will be releasing this change to our developer beta groups this week, by Friday 14th Jan 2022. We will then be targeting a public rollout of this change by July 10, 2022, providing a deprecation period of 6 months.

@SamLeatherdale we have connect 2 apps that rely on this feature, and giving us zero alternative and only 2 months to migrate to forge, where this same feature is still enabled is just bad form.

We are using this feature in combination with the page.view.selection/action-panel web item location in Confluence, which seems to be specifically designed for this use case as this is also what is described on the Use selected text in a Confluence Forge app page.

I would strongly urge you to consider keeping available for those situations in which the user selects the app through the context menu, or provide an alternative API for Connect comparable to Forge. There is no reason to force us to migrate to Forge only to have the same functionality.

CC: @bentley


Agree with @remie : why not offer the forge version of the API for connect?


I’m curious - you say “This presents a security and privacy risk to the user” but has anyone actually abused that in a connect app?

Not cool. You need to publish a roadmap of all the connect features that you are going to cripple and reasonable timeframes as well as detailed reasoning behind your decisions.

The “Forge is more secure” reasoning needs to be explained with details of the enhanced security. Also, exposing the equivalent Forge API to “connect on Forge” apps would be a reasonable middle ground, provided you give app developers a reasonable amount of lead time, say 6+ months (after Connect on Forge has gone GA).


Just to add up to the topic: the only source of the security submissions we see at Colined is not Connect. It’s XSS related issues caused by injections of valid JS code to assignee, epic, component, resolution, priority and other names. Atlassian API returns this code as is without any screening or sanitizing, so it’s us, vendors, to fix it in each and every UI we create. Yet another thing that consumes our development time.

This issue has been known for years. I’ve brought it up in person multiple times here, during calls with Atlassian and Bugcrowd representatives. Yet it’s still there without any intention of fixing it.

So, my question is: how do you pick those concerns? What happened so suddenly that you needed to remove that specific “risk”?


We’re supposed to build businesses on this “platform”. How long would Atlassian continue to use AWS as a vendor if you got 2 month deprecations?


Agree with what has been said by other vendors above. Also, why not just clearly declare this change as a breaking change? Instead, this post sounds like it is just a simple deprecation with a backward-compatible solution.

If your app does use this API, there’s nothing you need to do to keep your app running without errors.
The deprecation will be handled in a backwards compatible manner, the API will simply return the empty string "" under all circumstances.

This ugly “backward compatible solution” will produce silent errors, i.e. apps using this API will just not work anymore as expected but not produce errors. This is in many ways much worse than actually producing errors.

It is really discouraging to see an increasing amount of announcements formulated with simplistic solutions that make them sound like no big deal. I would like to see some more thought going into these announcements regarding

  • the actual impact on vendors
  • more carefully considered deprecation periods
  • clear explanation on why the change is necessary, not just “it is a security/privacy concern”

The most reasonable suggested solution seems to use Forge instead. However, like others already highlighted, for most vendors with Connect apps, this is not a 2-months quick-fix solution, apart from the fact that migration to Forge is for many simply not possible considering the current state of development of Forge.

Update: Just read this blog post again which says State 1 is a “Limited Alpha Release” and that Connect on Forge is actually not possible yet!?


@SamLeatherdale can you please comment on this?

@Bentley can we please discuss (perhaps separately) a CDAC policy for Atlassian Staff that if you post an announcement that you should be available to respond to replies within a reasonable time (even if that response is “Thanks for your feedback, we’re working on it”?

1 Like

@remie Thanks for your feedback, we’re working on it.

Could you please provide us the marketplace links of the two apps that you have published that use this API? That would be helpful for our analytics.

To be honest… no I can’t. Because at this stage in the relationship between Atlassian and the Marketplace Partners I’ve become to question Atlassians motives in regard to these types of decisions. What type of metric are you trying to get out of those app listings? Number of installs?

It’s not up to Atlassian to decide whether or not the apps that are using this feature are worth it to maintain the feature for Connect. The only valid question would be: can you please tell us how much you’ve invested in your app and your bank account number so that we can compensate you. I’m more than willing to sell my apps to Atlassian Ventures for them to kill it.

Atlassian introduced a feature to the Marketplace Partners and is removing it without a viable alternative. Despite being “GA”, Forge is not production ready. Connect on Forge is not past Phase 1.

If you really want to fix this security & privacy issue, there are three ways to do it properly:

  1. buy the apps of all vendors that are using this feature (with proper compensation) and take the hit with customers for killing the apps
  2. build the feature for connect in the same way as forge (context menu only, with app selection and only provide the text through this flow)
  3. wait for Forge to be a viable alternative to Connect

Anything else would just make Atlassian a very unreliable partner.


@SamLeatherdale ok, I know I said that I’d prefer a “Thanks for your feedback, we’re working on it” type of post, but after waiting 13 days I now realise that this was missing a vital part. What I meant was: “Thanks for your feedback, we’re working on it and we will get back at you in X days”. Could you revisit this topic and tell us when you expect to be able to respond with more detail?

Hi @remie, rest assured we have not forgotten about this thread, and have been working on a response internally. I can guarantee a full update will be posted by 2022-01-31T06:00:00Z.

Thanks for your patience.


Hi all

Thank you for your extensive feedback regarding this issue. We maintain that this feature does need to be deprecated, however after reviewing the usage of this API, we have determined that we can extend the deprecation period to the maximum permitted period of 6 months. This is a non-standard situation as usually vulnerabilities are handled in line with our vulnerability policy with a much shorter timeframe, hence our initial window of 2 months.

This means the revised public rollout date for this change would be July 10, 2022.

We also hear your feedback regarding the availability of this feature on Forge, and understand that it is far from a perfect solution. However Forge is built from the ground up to be more secure and private, and this API is an example of one which has been implemented in a much better way on Forge, and would not be trivial to backport to Connect, so there are no plans to do so currently.

If over the next few months, you find there are no alternate paths for your specific apps and this has become a blocker for your app, please continue to provide us with your feedback so we can find a solution that works for your app.

Thanks again for your patience while we were discussing your feedback.

1 Like

Hi @SamLeatherdale ,

Thank you for your detailed response, and for extending the deadline.

Given the decision, I would love to press both the Atlassian Security Team as well as senior Atlassian Ecosystem leadership to provide more clarity on the future of Connect. The community deserves better than slowly deprecating Connect features using Security as a pretext. In the end, everything can be back-ported to Connect if you just make the investment. It is a business decision from Atlassian to not further invest in the platform, and it would be great if you can be more upfront about it.

Obviously, making the decision to deprecate Connect is Atlassian’s prerogative, but I think Atlassian owes it to their Atlassian Marketplace Partners to be more transparant about the future of the platform. Personally, I would expect Atlassian to not deprecate features until Forge is on par with Connect, but I understand the milage of moral standards may vary.

Unfortunately, Atlassian has not shared an Org chart, so there is not really anyone I can tag from senior leadership in this discussion because I don’t know who that person would be. So I will just summon whomever I can hoping that they will convey this message within Atlassian.

@msuntinger @Bentley @nmansilla @dmorrow @ibuchanan


Hi @remie ,
Thanks for raising this. It’s a challenging topic and I know there are conversations within Atlassian about how we can improve our strategy and communication. I’ve shared your message with relevant folk within Atlassian.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.