Security Policy
Effective date: 4 October 2026
This page describes how IssueRescue for Jira is built and operated from a security point of view, and how to report a suspected vulnerability. It describes the app as it currently works; it is not a certification or a guarantee. IssueRescue does not currently hold any security or compliance certification and does not participate in the Atlassian Marketplace Security Bug Bounty program.
Hosting and data handling
- IssueRescue is an Atlassian Forge app. The app runs entirely on Atlassian's Forge platform, and we do not operate separate backend servers or databases for it. This public website is hosted separately and does not store or process data from your Jira site.
- The data IssueRescue stores (issue snapshots, deletion and restore records, and related indexes) is kept in Forge's hosted Key-Value Store. Atlassian scopes Forge-hosted data to each app installation, so each Jira site's data is held separately.
- IssueRescue's network calls go to your Jira site's own REST API, through Forge's built-in API client. The app does not declare permission to contact any external service, and it does not send your data to third-party services, analytics, or tracking tools.
- IssueRescue never asks for, or stores, Atlassian API tokens, passwords, or other credentials. It authenticates to Jira using identities that Forge provides at runtime.
- IssueRescue does not add any encryption of its own to stored data. Encryption is handled by Atlassian's platform: under Atlassian's Forge shared responsibility model, Atlassian is responsible for encrypting data at rest in Forge app storage and for encrypting traffic with TLS. Please refer to Atlassian's documentation for the current details.
- Snapshots record attachment details (file name, size, and type) only. Attachment file contents are not stored by IssueRescue and cannot be restored by it.
Administrator-only access
IssueRescue's admin page is placed in Jira's administration area. In addition to that, every action the page can perform (listing deleted issues, viewing restore history, restoring an issue, permanently deleting a stored snapshot, and index maintenance) checks on the server, before doing anything, that the person making the request currently holds Jira's global "Administer Jira" permission. That check asks Jira directly, as the requesting user, and does not rely on any user identity supplied by the browser. If the check cannot be completed, the action is refused.
Permissions the app requests
| Permission | Why IssueRescue needs it |
|---|---|
read:jira-work | To read issues, comments, worklogs, and related details so a snapshot can be captured while an issue still exists. |
write:jira-work | To create the replacement issue, comments, and worklogs when an administrator restores a deleted issue. |
storage:app | To store snapshots, restore records, and related indexes in Forge's hosted storage. |
report:personal-data | To take part in Atlassian's Personal Data Reporting, described below. |
Restore safeguards
Restoring an issue uses a per-issue lock in Forge storage, designed to stop a repeated or simultaneous restore request from creating a second replacement issue from the same snapshot. When rebuilding an issue, IssueRescue only sets fields that Jira reports as settable for the target project and issue type; fields it cannot safely rebuild are skipped rather than guessed. Some information can never be restored, including the original issue key and ID, the created date, the full change history, and attachment file contents. See the product page for details.
Snapshot retention
A snapshot of a deleted issue becomes eligible for automatic deletion 30 days after the issue was deleted. Eligible snapshots are removed by a scheduled daily cleanup, with additional checks whenever the app is used. An administrator can also permanently delete a deleted-issue snapshot sooner. Snapshots of issues that have not been deleted are kept and updated while those issues exist, and restore history records are kept as described in the Privacy Policy, which also explains what happens to stored data after the app is uninstalled.
Personal data reporting
IssueRescue stores Atlassian account references (for example, the reporter, assignee, and comment and worklog authors of a snapshotted issue). It takes part in Atlassian's Personal Data Reporting: once a week, the app reports the accounts it holds data for. When Atlassian reports that one of those accounts has been closed, IssueRescue erases that account's identifying data from its stored snapshots. When Atlassian reports that account details have changed, IssueRescue clears its cached display names for that account. See the Privacy Policy for more.
Logging
IssueRescue's application logs are kept within Atlassian's Forge platform. They are designed to record operational information such as issue identifiers, counts, status codes, and error messages, and are designed not to record the text of issues, comments, or worklogs, submitted field values, or credentials. When Jira rejects a request, the log may include Jira's own error message, which is not under IssueRescue's control.
Reporting a vulnerability
If you believe you have found a security vulnerability in IssueRescue, please report it privately by email rather than in a public forum:
Where you can, please include a description of the issue, the steps to reproduce it, and its potential impact. Please do not access, change, or delete data that does not belong to you, and avoid publicly disclosing a suspected vulnerability until we have had a reasonable opportunity to investigate it. We will review reports in good faith.
Changes to this page
We will update this page if the way IssueRescue handles security changes. The effective date above shows when it was last updated.