Security
What’s actually in place, not a checklist
This page describes real, current controls in the product, not a compliance checklist or a future roadmap. If something matters to you and isn’t listed here, ask us directly rather than assume.
Workspace isolation is enforced in the database, not just the UI
Every query that reads or writes a ticket, contact, deal, record, or file is scoped to the logged-in user's own workspace at the database layer. A member restricted to "own tickets only" can't see another workspace's data by guessing a URL or an ID: it isn't hidden, it's rejected server-side. This is covered by an automated test suite that specifically tries to cross workspace boundaries and asserts it fails.
Session cookies are encrypted and validated before anything ships
Login sessions are signed and encrypted with a secret that's required to be set, required to be at least 32 characters, and rejected outright if it matches the placeholder used in local development. A deploy without a properly configured secret refuses to serve production traffic rather than silently falling back to something weaker.
Security headers on every response
A Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, a Referrer-Policy, a Permissions-Policy, and HTTP Strict Transport Security are all set application-wide, tuned to the specific third parties Go1Desk actually loads (checkout and analytics), not a generic template copied in blind.
The inbound-email pipeline fails closed
The webhook that turns inbound email into tickets requires a shared secret in production; if that secret isn't configured, it refuses every request rather than quietly accepting unsigned ones. It's also rate-limited, both by sending IP and by destination address, to blunt abuse.
Automated tests gate every change before it ships
Workspace isolation, billing idempotency (a retried payment webhook can't double-grant access), and email-threading correctness all run as part of the same automated suite on every change, in continuous integration, before it reaches production.
Passwords are hashed, and two-factor authentication is available
No account's password is ever stored in plain text. Every account can turn on two-factor authentication from their profile, on top of Go1Desk's default one-time-code sign-in.
The most sensitive stored credentials are encrypted at rest
A connected channel's access token (the credential that lets Go1Desk read and send WhatsApp messages on a workspace's behalf) is encrypted with AES-256-GCM before it's written to the database, using a key that lives only in server configuration, never in the database itself. A tampered ciphertext is detected and rejected on decrypt rather than silently producing garbage that gets sent to Meta as a bearer token.
Where your data actually lives
Go1Desk runs on Oracle Cloud Infrastructure (Middle East region), fronted by Cloudflare for TLS termination, DDoS protection, and the security headers above. Our sub-processors (who they are and exactly what each one receives) are listed in the Privacy Policy.