Security and Responsible Disclosure

Current state

What's implemented

• Passwords are hashed with scrypt, never stored in plain text
• Session authentication uses an httpOnly, SameSite=Lax cookie, marked Secure in production
• Outbound webhook payloads are always HMAC-SHA256 signed — a signing secret is generated automatically the moment a webhook URL is configured, so there's no unsigned state to opt into
• Outbound webhook URLs are validated before every delivery attempt and rejected if they resolve to a private, loopback, link-local, or other reserved IP address (SSRF protection); redirect responses are never followed
• File uploads are restricted by an extension allowlist, size cap, and basic content-signature checks
• Workspace collaboration is enabled only for stable workspace ids on a server-side rollout allowlist; the active-workspace cookie never grants access, and current membership is checked from the database on every request
• Workspace invitation tokens are generated from 32 random bytes, stored in the database only as SHA-256 hashes, expire after seven days, and use a fragment/sessionStorage handoff so the bearer value is not placed in an ordinary query string
• Workspace activity feeds are membership-protected, private/no-store, and project only a closed set of event fields; response answers and integration credentials are excluded

Known gaps (not yet addressed)

• Encryption at rest for the database and uploaded files is unverified at the infrastructure level
• Uploaded files receive basic content-signature checks but no antivirus or malware scan
• No independent penetration test or security audit has been completed
• Workspace access is intentionally broad for current members; a removed member may retain data they downloaded or sent to another service before removal

Reporting a vulnerability