SpaceSite Draft

SpaceSite Security

Draft v0.1, 2026-10-01, not yet in force

This page describes how SpaceSite protects your data. It is written for Confluence admins and security reviewers. Facts marked NOT VERIFIED will be confirmed before the page goes live.

1. Architecture in ten lines

  1. SpaceSite is a Forge app installed in your Atlassian Cloud site.
  2. The app listens to page publish and update events in the space you enable.
  3. For each event it reads the page's HTML export and the list of attachments through the Confluence REST API, as the app, with read-only scopes.
  4. It signs the payload with HMAC-SHA256 and sends it over HTTPS to api.spacesite.dev, the only external host the app may contact.
  5. api.spacesite.dev is a Cloudflare Worker. It verifies the signature and the timestamp, then queues the page.
  6. The Worker converts the HTML, rewrites links, downloads attachments from signed Atlassian URLs, and stores files in Cloudflare R2 (EU jurisdiction) and metadata in Cloudflare D1 (EU location hint).
  7. A second Worker serves your Site on *.spacesite.dev or on your own domain, through Cloudflare for SaaS with automatic TLS certificates.
  8. A daily reconciliation job compares page versions and repairs missed events.
  9. When you delete the Site or uninstall the app, the app calls a signed purge endpoint and everything is removed within 24 hours.
  10. There is no SpaceSite database of users, no login system and no cookie on Sites unless you enable password protection.

2. What leaves your Atlassian tenant, and what does not

Leaves the tenant (sent to api.spacesite.dev) Never leaves the tenant
HTML export of published pages in the enabled space Atlassian OAuth tokens, API tokens, user credentials
Attachments and images of those pages Pages with view restrictions
Page title, hierarchy, labels, version number, page ID Pages labelled spacesite-exclude
cloudId and space key, as site identifiers Comments, page history, granular permissions
Author names and accountIds present in the export; stripped by the Worker before publishing unless you opt in Content of spaces you did not enable
Jira data, unless you enable the Jira snapshot in a later version

The admin's accountId and the app settings stay in Forge hosted storage inside your tenant.

3. Authentication and encryption

  • TLS 1.2 or higher on every connection: Atlassian to Forge, Forge to api.spacesite.dev, Cloudflare to visitors, custom domains.
  • Every request from the app to api.spacesite.dev carries a timestamp and an HMAC-SHA256 signature over timestamp and body. The Worker rejects requests outside the anti-replay window or with an invalid signature, and logs the attempt.
  • The HMAC secret lives in an encrypted Forge environment variable, different per environment (development, staging, production). Rotation is documented in our runbook.
  • No secret is shipped in the app bundle. We grep the build for secrets before each release.
  • R2 objects and D1 rows are encrypted at rest by Cloudflare.
  • Atlassian tokens never reach Cloudflare. The Worker downloads attachments only through short-lived signed URLs issued by Atlassian.

4. Permissions (Forge scopes)

The app requests read-only Confluence scopes plus app storage. It requests no write scope.

Confirmed scopes: {{SCOPES_CONFERMATI_S1}}

Candidate list, NOT VERIFIED until 13/10/2026: read:confluence-content.summary, read:confluence-space.summary, read:page:confluence, read:attachment:confluence, readonly:content.attachment:confluence, read:space:confluence, read:label:confluence, read:content.restriction:confluence, storage:app. Optional in a later version, only if you enable the related feature: read:jira-work.

External egress is declared in the manifest to one host only: api.spacesite.dev.

Because the app stores content outside Atlassian, it is not eligible for Atlassian's "Runs on Atlassian" badge and, in its current version, not eligible for Atlassian data residency ("PINNED") status. We state this in the Marketplace listing.

5. Access to published Sites

  • Sites are public by design. Review the private preview and the warnings report before each go-live; publication needs your explicit confirmation.
  • Password protection: one password per Site, checked by the Worker. A successful login sets an HMAC-signed session cookie. Login attempts are rate limited per IP.
  • Custom domains use Cloudflare for SaaS: you add a CNAME, Cloudflare issues and renews the certificate.
  • Visitors need no account. Sites set no tracking cookie and run no analytics.

6. Data residency

Component Location
Cloudflare R2 (site content, attachments) EU jurisdiction
Cloudflare D1 (metadata, sync state, aggregated counters) EU location hint
Cloudflare Workers (compute) Cloudflare global network; a request runs at the location closest to the caller
Resend (service emails) United States, us-east-1
Forge hosted storage (app settings) Your Atlassian tenant, under Atlassian's data residency rules

7. Retention and deletion

Data Retention
Worker logs (no page content, no tokens) 7 days
Export ZIP files and hosted previews 7 days
Site content, metadata, custom hostname Deleted within 24 hours after Site deletion or app uninstall
Aggregated usage events (no personal data) Kept for service statistics
Backups [OPEN]

8. Operations

  • One operator. Multi-factor authentication is enforced on the Cloudflare, Atlassian developer, Resend and domain registrar accounts.
  • Dependencies are pinned and updated regularly. The app is subject to Atlassian's passive Ecoscanner checks.
  • Production, staging and development are separate Forge environments and separate Cloudflare resources.
  • Logs contain request metadata only. No page content, no tokens, no passwords.
  • Incident response: if a security incident affects your data, we notify you at the admin email on file without undue delay [OPEN: proposed within 48 hours], with what we know and what we are doing.

9. Vulnerability disclosure

We welcome reports from security researchers.

  • Where: info@spacesite.dev. Put "Security" in the subject line. [OPEN: dedicated security@ alias]
  • What to include: affected component (app, api.spacesite.dev, a Site, spacesite.dev), steps to reproduce, impact, your contact.
  • Our commitment: first response within 5 business days; status updates until the issue is fixed; credit on this page if you wish.
  • Your commitment: test only against your own Atlassian site and your own Sites; no denial of service, no social engineering, no access to other customers' data; give us reasonable time to fix before publishing.
  • Safe harbour: we will not take legal action against good-faith research that follows these rules.
  • Out of scope: Atlassian and Cloudflare platforms (report to their programmes), issues that need physical access or a compromised device, missing best-practice headers without demonstrated impact.
  • There is no bug bounty. We do not pay for reports.

10. Contact

Security, privacy and support: info@spacesite.dev. Legal documents: Privacy Policy, DPA, EULA, Sub-processors.

11. Open points for the owner

  1. Replace {{SCOPES_CONFERMATI_S1}} with the manifest scopes after the Phase 0 verdict (13/10/2026) and delete the candidate list.
  2. Decide whether to create a dedicated security@spacesite.dev alias or keep info@.
  3. Decide the incident notification target (proposal: 48 hours).
  4. State whether R2 and D1 are backed up, and for how long.
  5. Confirm the anti-replay window and the session cookie lifetime once S2 and S3 fix them.
  6. Confirm the R2 EU jurisdiction and D1 EU location hint settings on the production account with a screenshot for the dossier.
  7. Cross-check every claim here against the dossier ยง 3 checklist (L2.1.7) before publishing.