Calendar Feed Security

Calendar Sync for Jira does not update any data in Jira. It is a read-only exporter.

Jira access rights

Calendar Sync for Jira is a Forge app. Rather than creating a user account to act on its own behalf, it declares the permissions it needs up front, and Atlassian enforces them. The app requests four:

The app declares no external hostnames, so it cannot send data anywhere outside Atlassian, even in principle.

If your Jira site is configured so that new users receive access to particular projects, configure those permissions before creating feeds. Otherwise, a feed may return fewer work items than you expect, or report a visibility error.

Where your data is stored

No data leaves Atlassian's infrastructure.

Your feed configurations and the generated calendar data are stored in the app's own storage inside Atlassian's Forge platform, in the same cloud environment as your Jira site. The app makes no outbound connections to third-party servers, and there is no external service to review, whitelist or trust.

The calendar data itself is only ever what you configured: the events produced from the fields you mapped on the Event Date & Time and Event Contents tabs, for the work items your query returned. Nothing else is copied.

This is a change from the Connect version of this app, which stored some calendar data on external servers outside Atlassian and reported errors to an external endpoint. Neither is the case on Forge. See Feature parity.

User authorisation

Every feed decides who can see it, on its Security tab. Access can be granted to:

• All users on the site

• Users in specific group(s) - named Jira groups

• Users with specific role(s) - named project-and-role pairs

• No one - which hides the feed from everybody

How access is resolved

• With group access, a user sees the feed if they are a member of any of the groups named.

• With role access, a user sees the feed if they hold any of the named roles in the project it is paired with. Membership counts whether it comes from being named directly on the role or from a group that is named on it.

Each rule must name both a project and a role. Jira's API cannot report which roles a person holds across every project at once, so the pairs are nominated rather than discovered.

Access control governs which feeds a user can see the URL for on their My Calendars page. It does not filter the events inside a calendar - every user who can see a given feed gets the same events from it.

Calendar data security

Calendar Sync for Jira exposes each calendar at a URL that does not require a sign-in.

This is necessary: most calendar applications cannot authenticate against an arbitrary service, so a feed they can subscribe to has to be fetchable with the URL alone. The same approach is used for shared calendars across the web, generally.

What protects the calendar:

• The URL cannot be guessed. It contains a random key generated for that feed, alongside the calendar's identifier. Knowing about the app or holding the URL of another calendar does not help anyone find it.

• All traffic is encrypted with HTTPS, so the URL and the data it returns are protected in transit.

• The key can be rotated at any time. An administrator can generate a new Auth Key on the feed's Security tab, which immediately invalidates every existing subscription.

What to be aware of:

• Knowing the URL is enough to read the calendar. The identifier and key in the URL are encoded, not encrypted. Treat a calendar URL as a secret: do not post it in a shared channel, a wiki page, a support ticket or a screenshot.

• If a URL is shared too widely, rotate the Auth Key. That is what the control is for. Users then re-subscribe using the new URL from My Calendars.

How the feed endpoint responds to bad requests

No information about the calendar, the feed or your Jira site is disclosed in any of the error responses.