Security Overview

Bulk Edit for Jira is built on Atlassian Forge - your data never leaves Atlassian's infrastructure. No external servers. No data egress. Minimal permissions.

Security highlights

  • Forge-native (Node.js 22.x) - no external servers or data egress.
  • Frontend runs as Forge Custom UI (React + Atlaskit) - all static assets from Atlassian CDN.
  • Storage in Forge KVS & Forge SQL - hosted and encrypted by Atlassian.
  • Zero external egress - no external API permissions, no outbound network calls.

Architecture

Bulk Edit for Jira is a Forge-native application built on Node.js 22.x, running entirely within Atlassian's managed infrastructure. There is no self-hosted server component.

  • Sandboxed execution: backend code runs in an isolated, managed runtime environment controlled by Atlassian.
  • Frontend: Forge Custom UI (React + Atlaskit) with static assets via Atlassian CDN.
  • Managed hosting: Atlassian handles infrastructure, scaling, and availability.
  • Built-in app identity: uses Forge authentication (asApp()) without stored credentials.
  • Content Security Policy: Forge enforces strict CSP headers to reduce XSS and exfiltration risk.

See Atlassian's Forge security documentation: https://developer.atlassian.com/platform/forge/security/

Network security

Bulk Edit for Jira makes zero external network calls. The only communication is between Forge runtime and Jira's internal APIs within Atlassian's infrastructure. There are no permissions.external entries in the manifest.

Data residency

When your Jira Cloud workspace is pinned to a region, data residency is automatic. If your admin changes location, data migrates automatically with your instance. No data is stored outside Atlassian's managed perimeter.

Authentication & authorization

Bulk Edit uses OAuth 2.0 via the invoking user's identity. Permission pre-flight checks ensure the user has BULK_CHANGE global permission and EDIT_ISSUES per-issue permission before any bulk operation begins.

  • read:jira-work - read issues, fields, projects, and filters to identify issues to bulk edit.
  • write:jira-work - update issues with new field values; transition issues.
  • read:jira-user - resolve user assigns and watchers.
  • storage:app - store undo snapshots, filter preferences, and operation logs in Forge Storage.

Async processing uses allowImpersonation only to ensure bulk operations inherit the invoking user's permissions.

Data protection

All data is encrypted at rest and in transit by the Forge platform. Undo snapshots (transient issue state for undo operations) are automatically purged after their TTL expires (7–30 days configurable). No personal data beyond Jira Account IDs is stored or processed.

Compliance

Bulk Edit for Jira is eligible for the "Runs on Atlassian" badge and inherits Atlassian's Forge compliance posture.

  • SOC 2 / ISO 27001: Atlassian's audit reports cover Forge infrastructure and security controls.
  • GDPR: No new personal data profiles are created - we only process existing Jira Account IDs and Atlassian-issued identifiers.
  • Zero external dependencies: Only the Forge SDK and Atlaskit UI components - no third-party APIs or analytics.

Incident response

In the unlikely event of a security concern related to Bulk Edit for Jira, contact [email protected]. We'll investigate and respond within 24 hours.

Contact

For security-related questions or to report a vulnerability: [email protected]