New sandboxing of Connect App Iframes in Confluence and Jira


For improved security we will be adding sandboxing to Connect App Iframes with the following initial allowlist:

  • allow-forms
  • allow-modals
  • allow-popups
  • allow-same-origin
  • allow-scripts
  • allow-top-navigation-by-user-activation (Firefox: allow-top-navigation)

This change has already been rolled out to sites in the Jira and Confluence Ecosystem Beta Groups for testing and will be rolled out to the general public beginning Wednesday 1st April (changed from Wednesday 25th March)

In general most apps should be unaffected, however if your app does anything outside of the allowlist you will be affected. Some examples are:

  • access window.parent or directly from inside your Iframe’s JavaScript
    (eg. setting without a user gesture)
  • modify document.domain of your Iframe or any nested Iframe

If this is the case, please reply to this announcement so we can grant your app an extension and work with you to find an alternative solution


Hello, we are using nested iframe in our plugin. Are these changes going to affect the plugin?

1 Like

Hi @nchakarov, welcome to the developer community!

Nested iframes will be affected under the following known conditions:

  • The app’s top Iframe and nested Iframe share a second-level domain, and manipulates document.domain in order to allow cross-frame communication.
    Please see a more detailed explanation here

This change breaks Scroll Documents in several places where we use parent.location.href = ... to redirect the user somewhere. The reason why we are using that method for redirecting at all is because of the following drawbacks in the Confluence Cloud JavaScript API:

  • AP.navigator.go only allows to specify customData when navigating to an addonModule. We need it as well when navigating to a contentview and to a contentlist, and I don’t see why it shouldn’t be allowed for any kind of navigator target.
  • AP.flag.create doesn’t allow to specify a href for the actions. This is not only annoying for the users, because they cannot open the action in a new tab, but it also forces us to manually redirect the user in reaction to the flag.action event.

It would be nice if those issues could be fixed and the sandbox be disabled until then.


You are giving vendors 1 week to check their software, signal problems here, and find a solution.

We are not affected as far as I can see, but I still cannot believe what I read.


Thank you very much, @dboyd

How can we make sure which instances are in the Jira Ecosystem Beta group? Because the instance I thought was in it isn’t showing any sandbox params on the iframes. :frowning:


1 Like

@dboyd The original post links to w3schools, but it might be more beneficial for community to use more exhaustive source of knowledge about sandboxing:


Hi @dboyd

This change will break a few navigation in our application, because we currently use"url", "_top"). We noticed that some features in our application broke yesterday, because of this change. We have tried several combinations using AP.navigator.go, but it does not work for us, because it has limited targets and it does not support concrete url at the moment. Please, grant our app an extension and what other alternative solution do we have.

Thank you.
SoftComply Team


We are using = in several cases in eazyBI and this will break our app functionality.

We are using it to redirect

  • from a configuration page to our general page
  • we use URLs with additional parameters in our emails - when user clicks the link and opens this email we capture additional URL parameters but then we want to redirect to the main app page without additional parameters.

Please do not do such quick change without allowing us to find if we can do any alternative solutions.


I enrolled and am seeing the sandbox properly in Confluence, but not in Jira. What should I do to get this addressed? I would like to get this fixed ASAP since we have so little time to implement any fixes.

1 Like

We also use = ... in multiple apps to redirect to other pages within Confluence. This is a very aggressive timeline to expect apps to react. Can you at least provide an API on AP to do safer redirects to pages within the host app?


We enrolled - nothing on the Jira side as well. @mpaisley @nmansilla help?

We tested the apps we were concerned about but they still seem to be working. We have another app that may be affected in some user use cases but I think we can workaround that with documentation.

Hi @dboyd,

There is a bitbucket-cloud tag in your post. How we can test our Bitbucket Cloud app before changes will be rolled out to the general public?


Hi @dboyd,

We are also using to redirect to the creation page of custom content in Confluence. This is a workaround because AP.navigator.go does not allow to go to the creation page, but only content view and edit (see Editcomponent for custom content).


1 Like

The list of targets for AP.navigator.go is limited. How can we redirect to an arbitrary Jira page, for instance, ticket search?

Thank you everyone for your feedback

The rollout will now be delayed until Wednesday 1st April in order to ensure vendors that are concerned have time to enrol in the Beta group and let us know if they need to be initially excluded

As stated in the announcement, if you have reason to believe your app is affected and request an extension you will not need your app to be fixed by this date

Please note that enrolling a site in the Beta group is a manual process at our end and may take a day or two.

If you are familiar with Chrome dev tools, you can test your app now in any product by adding the sandbox attribute and reloading your iframe.

In the top window in your dev tools console:

const myAppKey = "..."; // your app key
const mySelector = "iframe[id*='"+myAppKey+"']";
document.querySelectorAll(mySelector).forEach(el => el.setAttribute("sandbox", "allow-forms allow-modals allow-popups allow-scripts allow-same-origin allow-top-navigation-by-user-activation"));

Navigate to your iframe in the dev tools console:



First off awesome that Atlassian is improving security for Iframes.

We tried fixing our addon which uses to redirect to our app and link to certain of our own pages.

So we tried AP.navigation and it is not working for us. We have a webitem with a context of addon and it simply creates the wrong url…

  AP.navigator.go('addonModule', {'addonKey': 'nl.avisi.jira.plugins.relations-for-jira', 'moduleKey': 'atlas-crm-application', 'customData': {'route': '/settings/getting-started'}})

this generates:

  • https://{your-base-url}

But it should be

  • https://{your-base-url}

I think if you want to roll out changes like this it would be a very good idea to fix the AP.navigator API because this seems to be the main problem for all vendors.

But for now we would like to enroll with an extension for Atlas CRM for Confluence and for Jira until AP.navigator get’s fixed:


We have an app module k15t-docs-documents-overview-page that is configured to be the content list for the custom content type ac:k15t-scroll-document-versions-for-confluence:document. We want to navigate there and set the custom parameter activeDocumentId. So far we could do it like this:

parent.location.href = `${baseUrl}/display/SPACEKEY/customcontent/list/ac:k15t-scroll-document-versions-for-confluence:document?ac.activeDocumentId=123`;

Now we have two options:

AP.navigator.go('contentlist', { spaceKey: 'SPACEKEY', contentType: 'ac:k15t-scroll-document-versions-for-confluence:document' });
AP.navigator.go('addonModule', { addonKey: 'k15t-scroll-document-versions-for-confluence', moduleKey: 'k15t-docs-documents-overview-page', customData: { activeDocumentId: '123' } });

The first one doesn’t allow us to specify customData, and the second one doesn’t allow us to specify a spaceKey (and creates inconsistent URLs).

1 Like