TooLooLoo

Security policy, Worklog Reports for Jira

This is the security policy for the Jira Cloud app Worklog Reports for Jira, published by TooLooLoo. It states how to report a vulnerability, what is promised in return, and what the app does with the data it reads. Every claim below is enforced by the app's Forge manifest or by an automated test, and can be checked by a Jira administrator without taking our word for it.

Last updated: 28 August 2026.

Reporting a vulnerability

Write to support@toolooloo.fr Please include what you observed, the steps to reproduce it, and the app version shown at the foot of the report page.

What you get back:

Please report privately first and give us the time above before disclosing publicly. We will credit you when the fix ships, unless you prefer otherwise.

There is no monetary bounty. We would rather say so than imply one.

Scope

In scope: the app's Forge functions, its resolvers, its Custom UI page, the data it stores, and this website.

Out of scope: Atlassian's own products and infrastructure, which belong to Atlassian's bug bounty programme; findings that require a Jira administrator to already be malicious; and reports produced only by an automated scanner with no demonstrated impact.

What the app can reach, and what it cannot

No data leaves Atlassian. The app declares no external domain in its manifest and makes no outbound call. This is not a promise about our conduct, it is a property of the manifest: adding a single outbound address, even for an image, would remove the app from Atlassian's Runs on Atlassian programme, and eligibility is re-checked at every deployment.

There is no inbound entry point. The app has no web trigger. Every entry point is a resolver called from the app's own iframe inside your Jira site, or a scheduled trigger. There is no URL anyone on the internet can call.

Two permission scopes, both narrow. read:jira-work and storage:app. The app never writes to Jira, never modifies a work item, and never touches a worklog.

We hold no credential. Forge supplies the authenticated client. The app never asks a user for a Personal Access Token, a password or any other shared secret, and would have nowhere to put one.

Where your data lives

All of it is in Forge storage, hosted by Atlassian, on your own site. There is no database, no server and no third party. Because storage is Forge hosted, app data follows your site's data residency realm, and Atlassian handles pinning and migration.

Uninstalling the app removes its stored data with it. Your native Jira worklogs are untouched, because the app never wrote to them.

Who can read a report

The daily build runs with app permissions and can therefore see every worklog on the site. That is exactly why reports are stored per project and why the resolver checks the reader's own BROWSE_PROJECTS on that project before returning anything. A rebuild additionally requires ADMINISTER.

A shared link carries only the view: project, period, person filter and grouping. It carries no figure. Whoever opens it passes the same permission check on their own account, so a link cannot show anyone anything they could not have opened themselves.

Problem reports carry a fixed list, never your figures

A report filed through the in-app button is read by an administrator of your site and is meant to be forwarded to us, so it travels further than any figure on the page. It is filtered to eight named fields: app version, language, tab, period name, grouping, project id, browser, and the error. No hours, no names, no work item titles, no worklog comments.

The preview shown to the reporter is produced by the same function that stores the report, so what you are shown is what is stored. An automated test asserts the field list and searches the serialised form for leaks.

Development practices

Contact

support@toolooloo.fr