Collaboration app security checklist

• One canAccess(user, doc, action) function (action in read|comment|write|share|delete) gates every route and every stream; RLS scopes documents by workspace. The server rejects an update from a principal that lacks write, even if it holds a valid stream.
• Permissions are re-evaluated on a live stream every 60 s and immediately on a share change (NOTIFY); a revoked collaborator's stream is closed and their further updates return 403. Revocation latency target <= 60 s.
• Share-link tokens are 256-bit random, only their SHA-256 hash is stored, they are compared in constant time, expire by default, can be revoked, cannot exceed the creator's role, and public-link visitors are rate limited per IP and per token.

• Treat update payloads as hostile: reject anything over MAX_UPDATE_BYTES, reject documents that would exceed MAX_DOC_BYTES, decode and structurally validate in a size-bounded step before storing, and cap per-user update rate. A client may corrupt its own document view, never another document or the server.
• All billable and resource limits are circuit breakers that fail closed: per-workspace storage and monthly stream-hours, per-document connections, per-user document creation, export concurrency. At the limit the operation is refused with a clear error, not queued or degraded.

• Presence broadcasts only display name, colour and cursor; never email or user id of viewers who are not already collaborators. Document content is personal data when it contains it: stored per workspace under RLS, excluded from logs and traces, deletable, and never used for model training.

• Rich content is rendered through a schema-bound renderer (no raw HTML); pasted/embedded HTML is sanitised, embeds are allow-listed by origin, and comments are sanitised markdown with a CSP that blocks inline script.

• Embedded assets use presigned uploads with MIME + magic-byte verification, size caps, a virus-scan hook, and are served from a separate origin/path with Content-Disposition for non-images.

• Share, role change, link create/revoke, restore, export and delete write immutable doc_events rows with actor and IP hash.

• SSE/ws session tokens are short-lived (<= 15 min), bound to (user, doc) and refreshed in-band; link tokens and signing secrets never appear in logs, URLs of third-party requests or error messages.

• GDPR (applies to EU users): Documents, comments and presence reveal personal data: workspace-level export and erasure, per-document deletion that also deletes snapshots, a retention limit on version history, and a documented sub-processor list.
• Retention and legal hold (applies to business documents): Version history is a retention liability as well as a feature: configurable retention per workspace, deletion must purge snapshots and assets, and a hold flag suspends pruning.
• Accessibility: Keyboard-operable editor, screen-reader announcements for remote edits/presence, reduced-motion respect for live cursors, WCAG 2.2 AA.
• Children (applies to education or minors): If students under 13 can join shared documents, COPPA/parental consent and disabled public links by default apply.

• collab storage gb per workspace: per-plan cap on snapshots + log + assets; writes refused at 100% of quota.
• collab stream hours month: per-plan cap on concurrent SSE/websocket stream-hours; new streams refused over the ceiling.
• collab streams per node: MAX_STREAMS_PER_NODE hard cap (default 2000); excess gets 429, node count is capped, never auto-scaled without a ceiling.
• collab updates per user minute: token bucket per user per document; excess is rejected, not queued.
• collab export jobs month: per-plan cap on export jobs and bytes, enforced before a job is queued.
• collab asset egress gb month: per-plan egress cap on embedded assets via the edge cache; uploads and downloads refused at the ceiling.

Forge64 gives every app its own Postgres database and runs a quality gate that flags unauthenticated writes and secrets in client code before you see the app. It does not replace your own testing, and it holds no third-party security certification today.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as email, background jobs, file uploads and search are coming soon, so anything here that needs them is something you add yourself for now.

• Sign in as two different users and try to open each other's records by changing the id in the address.
• Submit each form with an empty value, a very long value and a script tag, and check the result.
• Call each write endpoint without signing in and check that it refuses.

What is the biggest security risk in a collaboration app?

One canAccess(user, doc, action) function (action in read|comment|write|share|delete) gates every route and every stream; RLS scopes documents by workspace. The server rejects an update from a principal that lacks write, even if it holds a valid stream.

Does a collaboration app have compliance obligations?

GDPR, if you have EU users: Documents, comments and presence reveal personal data: workspace-level export and erasure, per-document deletion that also deletes snapshots, a retention limit on version history, and a documented sub-processor list. This is a starting point, not legal advice.

Will Forge64 certify my app as secure?

No. Forge64 holds no third-party security certification today and does not certify apps. The checklist is a way to test your own app.

• How to build a collaboration app
• Collaboration app architecture
• Example prompt for a collaboration app
• Collaboration app scaling checklist
• Often combined: SaaS dashboard
• Often combined: AI document chatbot
• All app types