Jira access security
Query Feed for Jira does not update any data in Jira, it is a read-only exporter. Only read access is needed.
During the installation Jira Cloud will create an artificial "user" representing the add-on in the system. The user is called "Query Feed" and is visible in User Management like a regular user account (but it does not count toward the user limit). The add-on will use this account to read data from Jira and generate query feeds.
To control what the add-on can see, adjust permissions of this artificial user. If your Jira is configured in a way that does grant new users access to some information, it will be necessary to configure the permissions before using Query Feed for Jira. Otherwise the add-on will be unable to run queries, showing fewer issues than expected or even errors related to lack of project or issue visibility.
When used in Jira Server, Query Feed performs all operations as the user who is currently logged in. When a feed is exported, it will continue to use access rights of the user who created it. If the rights of this user to see some data are limited, it will affect the exported feeds as well.
Feed data security
The data URL provided by Query Feed for Jira is freely accessible. It contains an access token which is the only means of access control. Thanks to transport layer security (with HTTPS), the link, token, and data are safe from eavesdropping.
Each feed only exposes issues matched by a specific query, and only the configured fields. No other data is exported and potentially exposed.
Each feed has its own unique URL and access token. There is no risk of using the information about one feed to access data for another. The token can be invalidated and re-generated at any time, making the data inaccessible from the old URL.
The add-on supports CORS (cross-origin resource sharing), so the data URL can even be accessed directly by a serverless client-side web application. However, remember that in this case any user of the application may obtain the link and get access to the data directly. This approach is only recommended for cases when the data is effectively public anyway (for example exposed on a public website) or used by a narrow, trusted user base.
When more security is needed, you should keep the data URL safe on the server side of your application, and only expose data to authenticated users of your application.
The same advice applies to systems which use this data for some other processing (for example analytics). Be aware that the URL contains all credentials necessary for data access, and keep it safe when needed.