How we protect your data
A short, honest list of the controls in place today and the ones we are actively building. If a control is in flight, we say so.
Encryption of stored credentials
Third-party credentials pass through AWS KMS before they reach a database column: ad-platform and social OAuth tokens, CRM mailbox refresh tokens, and messaging provider access tokens and app secrets. Each ciphertext is bound to a workspace-scoped encryption context, so KMS itself refuses to decrypt one workspace's credentials on behalf of another. Other application data is not separately encrypted by us at the application layer.
Encryption in transit
API responses set HSTS with a one-year max-age and includeSubDomains, and in production also carry upgrade-insecure-requests. The one exception is our Swagger docs route, which keeps the shorter library default. We send the preload directive, but we do not claim a listing on the browser preload list. TLS is terminated by our hosting provider rather than by the application, so the minimum TLS version is a host setting this codebase does not pin.
Tenant isolation
Every workspace-scoped request passes through a guard that resolves the active workspace and verifies the caller's membership before the handler runs. Queries are then filtered by that workspace id. This is application-layer isolation only: Postgres row-level security is not implemented.
OAuth-only platform connections
We never ask for ad-platform passwords. Every connection is a scoped OAuth token. Disconnecting in Settings deletes our stored token and, for Meta and Google, also calls the provider's revoke endpoint on a best-effort basis. Platforms that publish no revoke endpoint are a no-op on our side, so you can also revoke the grant from the platform itself.
SOC 2: not certified
We are not SOC 2 certified and have no report to publish. If that changes, we will link the report here rather than describe it.
Audit logs
Connects, disconnects, member invites, role changes, and billing subscription changes each write a row to the workspace audit log. Members can read it in Settings as a paginated list. There is no export yet. The application only inserts these rows and never updates them, though nothing at the database level enforces that. A nightly job deletes rows older than the retention window, which defaults to 365 days.
Role-based access control
Four roles per workspace: owner, admin, member, viewer. Billing, integrations, and member management require admin or owner. Deleting a workspace and transferring ownership are owner-only. Roles are checked by a guard on every request, not just hidden in the interface.
Two-factor authentication
Two-factor authentication is email-based and opt-in per user from Settings. We email a six-digit code, store only its sha256 hash, expire it after ten minutes, and stop accepting it after five wrong attempts. There is no authenticator-app or hardware-key option, and 2FA is not required for any role today.
Responsible disclosure
Found something concerning? Email security@overads.io. We acknowledge reports within one business day and aim to triage within three.