Security

Wørkit holds an organisation’s project plans, client agreements, internal discussion and, where connections are enabled, credentials to other systems. The measures below describe how that is protected today. We have written what is true rather than what sounds reassuring, including the gaps in section 6.

Workspace data uses organization-scoped paths. Browser database access is checked by Firebase rules; server actions independently verify identity, membership, and permissions before using the Admin SDK.

• Writes are denied by default. Browsers cannot write directly to core organisation records directly. Server actions re-check identity and permissions. Personal notes, whiteboards, presence, and notification read state have separate rules for their specific owners or participants.
• Membership is the authorisation anchor. Shared cross-organisation spaces carry an explicit member list that the database rules check directly, so access cannot be inferred or spoofed by a client.
• Collaboration access is renewed. The server checks current membership before issuing a collaboration grant, which expires after 90 seconds. Private inboxes and personal canvases have owner-specific rules; shared notes and conversations require participant access.

When you connect Google, Slack, GitHub, Jira or Teams, the resulting token is a live key to another system. These are kept apart from ordinary data, deliberately.

• Credentials never sit inside the workspace. They live in separate stores that are unreadable by any browser, for any user, including administrators. Workspace members can see that a connection exists and whether it is healthy, but never the credential itself.
• Every outbound call happens server-side. A token is never sent to a browser, never appears in an error message, and never crosses into client code.
• Least privilege at the source. We request the narrowest permissions a feature needs: read-only for calendars, repositories and Jira; no message-history access for Slack or Teams.
• Disconnecting really disconnects. It revokes access at the provider where supported and deletes our copy, rather than keeping it for a future reconnect.
• Higher-risk keys are encrypted at rest with AES-256-GCM. We use this where a leak would be billed directly to your organisation, such as an AI provider key.

• All traffic is encrypted in transit with TLS.
• Stored data is encrypted at rest by our infrastructure providers.
• Private-file download URLs are issued after checking current access and expire after five minutes. Upload reservations check permissions, file type, size, and available platform capacity before accepting bytes. Avatars and workspace branding use separate display URLs.
• Confidential commercial figures on a shared engagement are stored outside the shared area entirely, so the organisation being quoted cannot read them regardless of what else it can see.
• An organisation may direct file uploads to storage it owns and controls, in which case those files never reside on our infrastructure.

• Authentication is handled by Firebase Authentication, supporting Google sign-in and email/password. Server sessions use HttpOnly cookies with Secure in production and SameSite=Lax protections. The server checks session revocation. Workspace setup binds the first administrator to the approved, verified owner identity and rejects repeated initialization. We never see or store a Google password.
• Sessions are re-verified on every server request, and the session cookie expires after five days.
• Administrative actions are recorded in audit logs and per-project activity feeds, so material changes are attributable.
• Roles and permissions are granular, letting an administrator grant only what a person’s job requires.

Stated plainly, so it does not surface as a surprise during procurement:

• No SOC 2 or ISO 27001 certification. We have not completed a third-party audit.
• No formal penetration-test report available to share.
• No customer-managed encryption keys. Encryption at rest uses keys managed by our infrastructure providers.
• No contractual data-residency guarantee. In practice, workspace data, files and our servers are in Mumbai, India, and live presence runs in Singapore. Sign-in runs on Firebase Authentication, a global service, and connected products process data in their own regions.
• No enforced SSO or SCIM provisioning for enterprise directories yet.

If any of these is a requirement, contact us before you commit. We would rather tell you now than have you discover it later.

If you believe you have found a security issue, email monikmalik.w.007@gmail.com with enough detail to reproduce it. We aim to acknowledge within 3 business days and will keep you updated until it is resolved.

The same contact is published in standard form at /.well-known/security.txt, and current service health is on the status page.

If we ever suffer a breach affecting your data, we will notify affected administrators without undue delay, with what we know and what we are doing about it.