Security

Security overview – Clocker for Jira

How Clocker protects your data, for security reviews and the Atlassian Marketplace security questionnaire.

Architecture

An Atlassian Forge app: a serverless backend function and a Custom UI front end, both hosted by Atlassian. There is no vendor-hosted infrastructure and no egress: the manifest declares no permissions.external entries.
Data at rest lives only in Jira (worklogs) and Forge storage (preferences, timers, site settings). See the privacy policy.

Permissions (OAuth scopes)

Scope	Used for
`read:jira-work`	Searching issues, reading issues, worklogs and permissions
`write:jira-work`	Creating, updating and deleting worklogs
`read:jira-user`	Reading the current user's profile (time zone) and global time tracking settings
`storage:app`	Preferences, timers and site settings in Forge storage
`report:personal-data`	Atlassian's weekly personal data report: erasing the data of closed accounts

The app requests no admin or configuration-management scopes.

Authorisation

Every Jira call runs as the current user (api.asUser()), so Jira's own permission checks apply to every read and write.
User-scoped storage keys come from the Forge invocation context (context.accountId), never from request payloads.
Changing site settings requires the Jira Administer global permission, checked on the backend for every save.
License enforcement happens on the backend for every operation that provides app value.

Input handling

Every resolver validates its payload: issue and worklog ids (allow-list regex), dates (YYYY-MM-DD, real calendar dates), times (HH:mm), durations (1 minute to 24 hours), comment length, settings schemas and list sizes.
REST paths are built with a template tag that percent-encodes every dynamic segment. Query strings use URLSearchParams. JQL is assembled only from validated dates.
The UI renders user-supplied text as text (React escaping) and never uses dangerouslySetInnerHTML. CSV export neutralises spreadsheet formulas.
Errors returned to the UI carry safe messages only. Unexpected errors are logged on the backend without payload contents.

Content Security Policy

The Custom UI runs in Forge's sandboxed iframe with the default CSP. The only relaxation is permissions.content.styles: unsafe-inline, which the Atlassian Design System's runtime styles require. No external scripts, fonts or images are loaded. Avatars are rendered as initials so no image hosts need to be allowed.

Dependencies

Runtime: @forge/api, @forge/resolver, @forge/kvs (backend); React, TanStack Query, @forge/bridge and Atlassian Design System packages (front end).
Lockfiles are committed. Every change runs through lint, type checks, tests, a production build and manifest validation before it can be deployed.
Deployments run only after those checks pass. The Atlassian API token used to deploy is an encrypted secret that only the deploy steps receive.

Reporting a vulnerability

Open a request in the support portal, or email support@niedzwiecki.dev with "Security" in the subject, with details and steps to reproduce. Please don't include customer data. We acknowledge reports within two business days and fix them within the timelines of Atlassian's Marketplace security bug fix policy.