Skip to content
Documentation
Mail for Jira and Confluence
Security

Security

Email is untrusted input from the whole internet, so the apps are built around one rule: mail content is data, never code, and it reaches your browser only after being checked.

Where your mail lives

The permanent copy of every delivered mail is content in your own Atlassian site: an attachment and, in Jira, an issue property. Your existing Jira and Confluence permissions govern who sees it. The backend keeps mail only transiently while delivering it; the privacy policy states the exact retention windows.

How the backend authenticates

  • Every call between Atlassian and the backend carries a signed Forge invocation token, verified against Atlassian’s published keys before anything is read or written. Panel actions additionally carry your user identity and run with your product permissions.
  • The per-site access tokens Atlassian issues to the apps are stored encrypted (AES-256-GCM) and are deleted the moment the app is uninstalled.
  • Incoming mail is only accepted for sites where the app is verifiably installed; everything else is rejected during the SMTP conversation.

How mail is rendered safely

  • HTML is sanitised before display. Message bodies pass an allowlist sanitiser when the panel loads them: scripts, event handlers, frames, and unsafe attributes are stripped. A hostile mail cannot run JavaScript in your browser.
  • Images go through a proxy. Images referenced by a mail are fetched through the app’s backend using short-lived signed URLs minted only for a viewer who was just authorised to read that history. Sender-hosted images are fetched by the backend, not your browser, so a sender cannot use tracking pixels to learn your address, location, or reading time; the proxy also refuses requests into private networks, enforces size limits, and caches responses briefly.
  • Attachments open through the product. Attachment links lead to Jira or Confluence, which apply their own permission checks and virus handling.

What the apps do not do

  • No outbound mail of any kind: no auto-replies, no forwarding.
  • No analytics, advertising, or tracking in the panel; no cookies and no browser storage.
  • No access to issues or pages beyond the one whose panel you opened, and no reading of site content that is not part of a mail history.

Operational logging

The backend keeps operational logs to run and debug the service. They contain identifiers (which site, which issue or page, whether a delivery succeeded, and why it failed) and never message bodies or attachments.

Responsibilities that stay with you

  • An address is a capability. Anyone who knows an item’s address can add mail to it, and that mail is visible to everyone who can see the item. Share addresses deliberately; treat a leaked address the way you would treat a leaked upload link.
  • Mail content is site content. Once delivered, a mail is subject to your site’s own permissions, retention, and export. Configure those in Jira and Confluence, not in the app.

To report a security issue, contact support@atlas-cloudlet.atlassian.net.