Security

Authority is checked on the server

The app uses Forge's backend installation and user context, current Jira permission checks and per-project setup. A browser-supplied account ID, URL, object identifier or approval flag cannot grant authority. Installing the app does not automatically enable projects. Global Jira-administrator and project-administrator permissions are checked for their respective actions.

Jira administrators select projects and an approval policy. In the structural policy, project administrators can apply supported changes to existing configuration only after isolation is established. New Screens and Screen Schemes need approval by another currently authorised Jira-administrator account. Administrators can require review for every request. Unknown dependencies or an unsupported configuration stop the change.

Change execution and audit

Plans retain before/after field layouts, configuration fingerprints, relevant policy/setup revisions and the requester. Execution checks the current configuration and authority again, writes a durable intent, records an acknowledgement where available and verifies the resulting effect. Write stops and disabled project access block subsequent steps. They cannot undo a Jira request already sent.

Uncertain outcomes are retained for inspection. The app does not blindly retry configuration writes or promise universal rollback. Jira configuration updates are not a single atomic transaction, and a separate administrator can change Jira between checks. History records request, review, execution and recovery decisions without treating old approvals as fresh authority.

Data protection in operation

The reviewed app uses Atlassian-hosted Forge storage and Jira APIs with no configured third-party runtime backend or analytics service. Local backup encryption uses AES-256-GCM with a passphrase-derived key. A passphrase stays in the user's browser; it is not sent to the app backend. This protects the exported file, not every customer-created copy or every support attachment.

Runtime fault messages use sanitised codes rather than raw provider responses or personal identifiers. Saved audit records and free-text decision notes remain potentially sensitive and are subject to access and retention decisions. Current user display names are fetched from Jira rather than saved in a profile directory.

Scope and assurance limits

Jira grants app permissions at site level. App-level project enablement and server-side checks constrain their use; they do not turn the underlying grant into a project-scoped credential. Review the permissions shown by Atlassian when installing or upgrading.

The implementation has automated logic and browser coverage, complete-content Aikido checks of changed code and recorded internal TEST acceptance. These are engineering checks, not a penetration-test certificate, a SOC 2/ISO certification of this app, a guaranteed recovery-time commitment or proof of arbitrary tenant scale. No Marketplace badge is claimed before it has actually been awarded.

Report a concern

Use Security report in support portal. Describe impact, affected version and a minimal reproduction with synthetic data. Do not exploit another tenant, access unrelated data, publish a credential or repeatedly test a live write. If the portal is unavailable, contact tfitzner90@gmail.com.

The provider will assess reports, preserve relevant evidence, coordinate containment and communicate through an agreed private channel. Notification obligations and remediation priorities follow applicable law and the Atlassian Security Bug Fix Policy; there is no separate bounty or 24/7 service commitment.

Project groups and same-project sharing

A Jira administrator may restrict an enabled project to selected existing Jira groups. The server still requires current administrator rights in that project; belonging to an allowed group never grants those Jira rights. Membership is checked again for authorised requests, approvals and execution. A failed or unavailable check blocks access, and the UI hides previously loaded protected content when authority is lost. A changed project access configuration invalidates earlier unexecuted requests.

Same-project shared changes are separately opt-in. Their sealed request records the user’s explicit acknowledgement. Every affected type must currently belong to the enabled project and pass fresh field and dependency checks. Ownership and workflow guards still apply, direct cross-project shared writes remain blocked, and new configuration needs another Jira administrator’s approval. Shared field additions/removals affecting View remain outside the accepted capability. These safeguards do not make a multi-step Jira change atomic.