Skip to content

Security

This page describes where Issue Link Guard runs, how it checks permissions, which Jira permissions it asks for, and what happens to its data. What the app stores is listed on Data and privacy.

Where the app runs

Issue Link Guard is built on Atlassian Forge and runs entirely on Atlassian's infrastructure. It has no servers of its own and sends no data to any outside service: the app declares no external domains and no remote back ends.

  • Data residency. The app keeps its data only in Forge hosted storage (the Key-Value Store and Forge SQL), which stays in the same location as your Jira site and moves with it when an admin moves Jira to another location.
  • Tenant isolation. Forge keeps each site's data in a separate partition. The app's short-lived in-memory caches are keyed by the site's installation, so one site's data is never served to another.
  • Logs. The app's logs contain the kind of event, counts, issue and project keys, and error codes such as "HTTP 403". They never contain account IDs, names, issue content or the text of Jira's responses.

How permissions are checked

  • Rules are enforced on the server. Hiding a link type in the window is only a convenience. Every request to create or remove a link is checked again on the server against the project's rules, so a rule cannot be bypassed by calling the app directly.
  • Users act with their own permissions. By default the app talks to Jira as the signed-in user. A user can only search for, see and link issues they can already see in Jira.
  • The technical account does not widen access. When the app's account changes links for a user, the app first confirms, as that user, that the user can view both issues and can edit the issue or has "Link Issues". The only exception is the project option for linking from the side panel without permission to edit, which a project administrator turns on deliberately; viewing both issues is still required. See Technical account.
  • Links chosen on the create screen are checked for the creator. The app's account creates them after the issue is saved, because no user is signed in at that point. Before creating each link, the app asks Jira whether the person who created the issue can see the target issue, and applies the project's rules to that person. If the project does not use the technical account, that person must also have "Link Issues".
  • Checks fail closed. If the app cannot read a project's rules, or cannot determine a user's groups or roles, it refuses the link instead of allowing it.
  • Settings pages check the caller on the server. Project settings require the Administer Projects permission in that project, or Administer Jira. The admin page requires Administer Jira.
  • The app changes only its own permission entry. In a permission scheme, the app can add a "Link Issues" entry for its own account, and only when a Jira administrator asks it to. It never changes or removes entries for users, groups or roles.
  • The license is checked on the server. Without an active license the app does not create or remove links, whatever the browser sends.
  • The activity log is shown only to people who can view the issue. The server checks this for every request; hiding the tab is not the only protection.

Jira permissions the app asks for

Scope Why it is needed
read:jira-work Reads issues, projects, issue link types, project roles and permissions to show and enforce link rules: the link window lists existing links and suggests target issues, the app checks the user's Browse, Edit and Link Issues permissions before every change, and it listens to the "issue created" event to create links chosen on the create screen.
write:jira-work Creates and deletes the issue links users request in the app's fields and side panel. Adds a comment on both issues when the project has that option on. Records which links a picker field created (link type, direction and issue IDs only), so the field shows only its own links.
read:jira-user Evaluates "who may link" rules based on groups, and lets project administrators search for users and groups when configuring rules. Display names are read when shown and are not stored.
manage:jira-configuration Adds the app's own account to the "Link Issues" permission of a project's permission scheme when a Jira administrator turns on the technical account, and reads the configuration of the app's own picker fields.
manage:jira-project Writes one project property when a project administrator saves the app's project settings. Jira reads it to show the app's side panel only in projects where it is turned on.
write:app-data:jira Clears the values of the app's own custom fields after an issue is created (the values only carry the links to create), and hides the app's Activity tab when an administrator turns the activity log off.
storage:app Stores the app's own data in Forge hosted storage: project rules and settings, the technical account switch per project, privacy settings and the list of account IDs reported to Atlassian.
report:personal-data Reports the account IDs the app stores to Atlassian's personal data reporting API, so the app can erase the data of closed accounts.

What appears in Jira's own history

  • A link created by a user through the app appears in the issue's History under that user's name, like any other link.
  • A link created by the technical account appears in History under the app's account. The person who requested it is recorded in the app's activity log and, if the project has that option on, in a comment on both issues.

When the app is uninstalled

  • Data in Forge hosted storage (project rules, settings, the activity log) is deleted by Atlassian: it is first soft-deleted and kept for a short retention period, about 28 days, so it can be recovered if the app is reinstalled by mistake, and then destroyed.
  • If you reinstall the app within 21 days and want the previous data back, contact support; Atlassian can relink it to the new installation at the vendor's request.
  • Picker link lists are stored as issue properties in Jira and stay on the issues. They contain only link types, directions and issue IDs.
  • Comments added by the technical account are regular Jira comments and stay on the issues.
  • Links created through the app are regular Jira links and stay.