FernlightSecurity
Applies to API Docs for Confluence and all Fernlight apps
Architecture
| Area | How it works |
|---|---|
| Hosting | Atlassian Forge. The app's code runs in Atlassian's managed runtime, and there are no Fernlight servers. |
| Data egress | None. The app declares no external fetch permissions, and Forge blocks any outbound network call that isn't declared. The app is eligible for Atlassian's Runs on Atlassian badge. |
| Data storage | Specs are Confluence page attachments, and settings live in the page. The app uses no Forge storage and no external databases. |
| Data residency | Content stays in your Confluence site, so it follows your organisation's Atlassian data residency settings. |
| Access control | Every Confluence API call is made as the current user (asUser), so page and space restrictions are always enforced. The app never reads content with elevated app permissions. |
| Secrets | The app stores no API tokens, passwords or credentials. |
| Front-end isolation | The UI runs in a sandboxed Forge Custom UI iframe under Atlassian's Content Security Policy. Markdown in specs is sanitised with DOMPurify before it is rendered. |
| Spec parsing | External $ref references are never resolved, so a spec cannot make the app fetch remote URLs or local files. |
Permissions requested
| Scope | Why |
|---|---|
read:page:confluence | Identify the page that hosts the macro. |
read:attachment:confluence, readonly:content.attachment:confluence | List spec attachments and their versions, and download them for rendering and comparison. |
write:attachment:confluence | Save a pasted or uploaded spec as a page attachment. |
read:confluence-content.all | Required by the attachment download endpoint used for PDF/Word export. |
Development practices
- Dependencies are pinned in lockfiles.
- Parsing, filtering, linting and change detection are covered by automated tests.
- We follow Atlassian's security requirements for cloud apps.
Reporting a vulnerability
Email security@fernlight.dev with a description and the steps to reproduce. We acknowledge reports within 2 business days, and aim to fix critical issues within 7 days and high-severity issues within 28 days, in line with Atlassian's vulnerability SLAs. Please give us a reasonable opportunity to fix an issue before you disclose it publicly. We will not take action against good-faith research that avoids privacy violations and service disruption.
Incidents
If a security incident affects customer data, we will notify affected customers and Atlassian without undue delay, and within 72 hours of becoming aware of it.