Secret payload
The sensitive text entered by the user, such as passwords, tokens, certificates, private keys, or other confidential content. This is stored in the Forge Secret Store and never written into the page.
// secret notes for confluenceSecurity &
Security &
Privacy.
A factual overview of how Secret Notes for Confluence handles sensitive note content, page storage, copy-safety, permissions, retention, and platform boundaries.
// summary
Runs on Atlassian, without an external backend.
Secret Notes for Confluence is built as an Atlassian Forge app. You drop a Secret Note element into a page and store a password, token, key, or certificate in it; the plaintext lives only in the Atlassian Forge Secret Store, never in the page.
HostingHosted on Atlassian Forge infrastructure. No Forge Remote and no external Verdaro Labs app server for secret handling.
Secret storageSecret plaintext is stored in the Atlassian Forge Secret Store. Non-secret metadata is stored separately in Forge KVS.
Nothing in the pageThe page body stores only an opaque reference id. The secret and its metadata are never written into the page, its version history, the search index, or exports.
No telemetryNo analytics, advertising trackers, third-party telemetry, or external error-reporting SDKs are used by the app.
No sub-processorsThere are no third-party sub-processors. The only outbound calls the app makes are to Atlassian’s own APIs; no data is sent to Verdaro Labs or to any other vendor.
Data residencyAll storage is Forge KVS and the Forge Secret Store, so the app inherits Atlassian’s data residency for the install’s home region. The app keeps no copy of your data anywhere else.
// data processed
What data the app handles
Note metadata
Note label, the bound page identifier, Atlassian site/cloud identifier, creator metadata, selected reveal audience (users/groups), guest setting, expiry/status information, counters, and metadata-only audit events.
Personal data
The app stores Atlassian account IDs and display names in note metadata and audit events — for the note creator, any users named in a restricted audience, and the actor on each audit event. They are used to enforce reveal permissions and to make the audit trail readable. They are never sent to a third party, and they are reported to Atlassian’s Personal Data Reporting API so closed accounts can be erased.
Retention
Secret payloads follow the note’s expiry policy, with a 365-day maximum in every case. Metadata for a note that has been revoked, expired, or self-destructed is deleted automatically after 90 days; it holds the audit trail, never a secret. Each note retains its most recent 100 audit events. Uninstalling the app purges the site’s stored data.
// storage boundaries
Where plaintext is not written
The app is designed to avoid the common problem of secrets being pasted into the page body, where they leak into exports, version history, and search.
Not the page bodyThe page stores only an opaque reference id as the macro parameter, never the secret or its metadata.
Not version historyEvery historical version of the page contains only the opaque token, never the secret.
Not exportsPDF, Word, and space exports render a neutral placeholder; the secret is never serialized into an export.
Not the search indexConfluence indexes page storage; the token is meaningless and the plaintext was never there.
Not normal KVS metadataForge KVS stores note metadata, not the secret plaintext payload.
Not logs or audit eventsAudit events are metadata-only and do not contain the revealed secret value.
Not Verdaro Labs serversThe app does not send secret plaintext to an external Verdaro Labs backend.
// copy-safety
Copying a page does not copy the secret
Each secret is bound server-side to exactly one page. When a page is copied, the copied element carries the same opaque reference, but the app refuses to reveal it on the copy because the copy is a different page. A copied reference is a dead link, not a leak.
Moving a page (which keeps the same page identity) keeps the secret revealable for authorized users; copying does not.
// access control
Permission and reveal model
Authorization is enforced server-side in Forge resolvers using the Atlassian-signed account identity. The browser UI is not treated as a security boundary for reveal, revoke, visibility, or audit decisions.
- The element only renders for users who can already view the page, so page permissions and restrictions form the first access floor.
- Creators can reveal, replace, and revoke their own notes, and see the note's audit trail.
- A note can be available to anyone who can view the page, restricted to selected users and/or groups, or limited to the creator only.
- External/guest collaborators are blocked by default and can reveal only when the creator explicitly allows guests on a page-viewers note.
- Anonymous users are blocked from reveal access.
// lifecycle
Expiry, deletion, and audit
Read onceA read-once note is designed to self-destruct after the first successful reveal by a reader, who is asked to confirm first. A reveal by the note’s own creator is a non-consuming preview: they already hold the plaintext they typed, and burning the single read on the author would destroy the secret before its intended reader ever saw it. Previews are audited and increment the view count, which every viewer can see. The trade-off we accept: an attacker on a compromised creator session can re-read that creator’s read-once secrets without triggering the self-destruct — though they could equally revoke them, rotate them, or reveal once and keep the value. The account compromise is the loss, not the preview rule.
Time limitsNotes can expire after 1 hour, 24 hours, or 7 days. “No expiry” notes remain until revoked, with a 365-day Forge Secret Store TTL backstop.
Manual revokeCreators can revoke a note at any time to destroy the secret immediately — including when a Marketplace subscription has lapsed.
CleanupExpired and destroyed secrets are cleaned up best-effort during normal app operations.
Page deletionDeleting a page makes its secrets permanently unreachable — the page can no longer render the element, and server-side page binding refuses a reveal from anywhere else. The stored payload is then destroyed by its secret-store TTL, at most 365 days. The app deliberately does not subscribe to Confluence page trash/delete events: those events require a content write scope we do not request, and purging on trash would destroy secrets on pages that are later restored. Revoke remains the immediate destroy path.
UninstallThe app includes an uninstall handler designed to purge tenant app data when the app is uninstalled, subject to Atlassian platform behavior and backups outside direct app control.
User anonymizationThe app uses Atlassian’s Personal Data Reporting API. On a weekly cycle it reports the Atlassian account IDs it stores; accounts Atlassian reports as closed have their stored references erased and replaced with a non-identifying tombstone, and accounts reported as updated have their display names refreshed. Erasure therefore completes within the reporting cycle rather than instantly. Secret payloads are unaffected — they contain no personal data and follow their own expiry lifecycle.
// important boundary
Clipboard and user handling
When a user reveals or copies a secret, that plaintext leaves the protected storage context and becomes visible to that user. If copied, it enters the operating-system clipboard.
Clipboard managers, browser extensions, operating-system sync features, or other tools outside the app may retain clipboard contents. Secret Notes warns users about this boundary, but cannot control software outside the Forge iframe.
// questions
Open supportSecurity or privacy question?
For app security, privacy, or Marketplace review questions, contact Verdaro Labs through the support channel.