Security Policy

1. Platform & hosting

File Field for Jira is a Forge app: its backend logic, storage, and UI surfaces all run on Atlassian-operated infrastructure, inside Atlassian's Forge sandbox. Contextra Labs does not host, operate, or have direct access to any server, container, or database behind this app.

The app's manifest declares no external domains. It makes no network call to any Contextra Labs endpoint or third-party service — not for analytics, error reporting, telemetry, licensing, or any other purpose. Every request the app makes stays inside Atlassian's platform APIs.

Because of this, the security of the underlying compute, network, and physical infrastructure is governed by Atlassian's own security program, including encryption in transit and at rest, which Atlassian applies uniformly to all Forge apps and to Jira itself.

2. Access control & permission scopes

The app requests only the Forge scopes it needs to function, and nothing broader:

• read:attachment:jira — read attachment metadata for Portable-mode fields
• write:attachment:jira — attach uploaded files as Jira attachments in Portable mode
• delete:attachment:jira — remove the underlying attachment when a Portable-mode file is deleted
• read:jira-work — read issue and field context needed to render the field, and re-verify the calling user's own Jira permission before returning a field's files
• write:jira-work — save the field's value when files are added or removed
• storage:app — read and write the app's own Forge key-value store and Object Storage bucket

End-user identity and session handling are entirely Atlassian's: the app never sees a password, session token, or API credential, and never implements its own authentication. Every action the app takes runs under Forge's own invocation context, scoped to the calling user and site.

Before returning a field's file list or content, in both storage modes, the resolver re-checks the calling user's own permission to view the issue against Jira's own API — a client-supplied identifier is never trusted outright. This closes the standard "confused deputy" risk for a resolver like this one, but it is Jira's ordinary issue-view permission being enforced, not a separate per-field access control: neither storage mode restricts a field's files to a narrower group or role than the issue itself grants. See the Privacy Policy for how this affects what each mode protects.

3. Upload validation & content safety

File uploads are validated server-side, not only in the browser, so a client that bypasses the UI cannot bypass the rules:

• Type allow-lists — a field only accepts the file categories/extensions its configuration allows; everything else is rejected
• Size and count limits — enforced per field, with a default 10 MB per file
• Content-signature verification — the app inspects a file's actual magic bytes and rejects it if the content doesn't match the claimed extension, catching a disguised or renamed file (for example, an executable renamed to end in .pdf)

Uploaded bytes are never executed, parsed for macros, or opened by the app itself — they are stored as opaque binary content and handed back to the browser unchanged when downloaded.

4. Data storage & isolation

Where file content and configuration are stored depends on the field's storage mode, detailed in the Privacy Policy:

• Portable mode — files are ordinary Jira attachments, in Jira's own attachment storage, subject to Jira's existing permission model
• Private mode — files are stored in Forge Object Storage, a bucket Atlassian provisions per installation and isolates from every other app and every other site's installation
• Configuration (rules, mode) — stored in the app's Forge key-value store, likewise isolated per installation

Uploads and downloads move directly between the user's browser and Atlassian's storage APIs using short-lived, cryptographically signed URLs; the app's own backend code never receives or buffers the raw file bytes.

5. Licensing & subscription checks

Licence status is supplied by Atlassian and checked before any state-changing action (uploading, deleting, or reconfiguring a field). The app does not operate its own licence server or store licence data outside Atlassian's platform.

6. Vulnerability management

Dependencies are kept current and the app is rebuilt against the latest supported Forge runtime; the underlying platform patching (Node runtime, sandbox, infrastructure) is handled by Atlassian as part of the Forge managed environment. Contextra Labs reviews and applies security-relevant Forge platform advisories as they are published.

7. Reporting a vulnerability

If you believe you've found a security issue in File Field for Jira, please report it privately to support@contextra-labs.com rather than filing a public issue. Include steps to reproduce and, where possible, the affected Forge app version. We aim to acknowledge reports within two business days and will keep you informed as we investigate and remediate.

Please do not access, modify, or exfiltrate data belonging to a site you do not control while testing — use a test site you own or one where you have explicit authorization.

8. Incident response

Should a security incident affecting this app be identified, Contextra Labs will investigate, take reasonable steps to remediate, and notify affected customers without undue delay where the incident materially affects their data, consistent with our obligations under the Terms & EULA. Because the app holds no infrastructure of its own outside Atlassian's platform, most infrastructure-level incidents are disclosed and handled directly by Atlassian's Trust Center.

9. Changes to this policy

Material changes will be published on this page with an updated effective date, and noted in the app's release notes.

10. Contact

support@contextra-labs.com

See also the Privacy Policy and Terms & EULA for File Field for Jira.