SalesOS Trust Center

SalesOS runs on Oracle Cloud Infrastructure (OCI) in the Mumbai region (ap-mumbai-1), India. The web app is served as static files by nginx, the API is a NestJS service, and the PostgreSQL 12 database runs on the same host and accepts connections only from that host.

Cloudflare sits in front of salesos.org for DNS and proxying. Browsers connect to Cloudflare, and Cloudflare connects to our server over TLS using a Cloudflare origin certificate.

In transit

• Plain HTTP requests are redirected to HTTPS.
• Only TLS 1.2 and TLS 1.3 are accepted, both at Cloudflare and at our server.
• API responses send Strict-Transport-Security (one year, including subdomains) and a Content Security Policy.

At rest

• Passwords are hashed with bcrypt (cost factor 10). We never store them in readable form.
• Stored secrets are encrypted in the application with AES-256 before they reach the database: integration credentials, OAuth app credentials and payment gateway settings use AES-256-GCM; SSO client secrets, LLM provider keys, two-factor secrets and Salesforce tokens use AES-256-CBC. The key is held on the server, not in the database.
• Two-factor backup codes, SCIM tokens and API keys are stored as hashes.
• OCI encrypts its block and boot volumes at rest by default with Oracle-managed keys. We do not add separate operating-system disk encryption.

• Passwords must be 12 to 128 characters with an uppercase letter, a lowercase letter, a number and a symbol.
• After 10 failed sign-in attempts the account is locked for 15 minutes.
• Access tokens last one hour and are renewed while you keep working. You can sign out a single session or all your other sessions under Settings → Security, and resetting your password ends every session.
• Two-factor authentication with an authenticator app (TOTP), plus 10 single-use backup codes. Platform administrators can require it for all users, for admins or for managers, with a grace period to enrol.
• Single sign-on per organization with SAML 2.0 (signed assertions required) or OpenID Connect (authorization code flow with PKCE). An organization can require SSO for its email domain, which turns off password sign-in for those users.
• SCIM 2.0 provisioning for users and groups. Tokens are scoped to one organization, and deprovisioned users are deactivated, not deleted.
• API keys are stored as hashes and can be scoped per resource, given an expiry date and limited to listed IP addresses.
• State-changing requests from the web app need a CSRF token tied to the session.

Every organization's records carry its organization id. Each signed-in API request passes an organization guard that confirms you are an active member of the organization you are acting in and that the organization is active, and the services filter their database queries by that organization. Screens that read across organizations are limited to SalesOS platform administrators.

PostgreSQL row-level security policies are defined on 22 core tables, including leads, contacts, accounts, deals, quotes, orders, tasks and notes.

• Two kinds of role: a platform role (Admin, Manager, User, Viewer) and a role in your organization (Owner, Admin, Manager, Member).
• Profiles set per-module permissions (read, create, edit, delete) and record visibility (none, own, team or all) for the users they are assigned to.
• Field-level security hides or locks individual fields on leads, contacts, accounts, deals, tasks and cases, both in responses and on save.
• Record sharing grants a user or a team read or edit access to one record, optionally until a set date.
• Bulk ownership transfer is always confined to your own organization, is capped per request, and can be previewed before it runs.

• Administrative actions (user and role changes, configuration changes, impersonation, bulk transfers, DPA acceptance) are written to an admin audit log.
• Field-level change history is recorded automatically for accounts, deals, contracts, quotes, orders, leads and contacts, showing who changed what and when.
• Successful and failed sign-ins are logged.

We take full PostgreSQL backups with pg_dump. The backup script keeps the seven most recent, and a restore can be run from any of them.

The status page checks the API, the database, background jobs, AI availability and email delivery live, every time it loads, and shows any service notice we post.

Email [email protected] with the steps to reproduce the issue and how to reach you. Our contact details are also published in security.txt.

• Test only against your own account and organization. Do not access, change or delete other customers’ data.
• Do not run denial-of-service tests, spam or social engineering against our staff or customers.
• Give us a reasonable amount of time to fix the issue before you share it publicly.
• We do not run a paid bug bounty.

If you think your account or data has been compromised, email [email protected]. Settings → Security lets you sign out every other session straight away, and a password reset ends them all.