Security

A short technical summary of how DDM Flow secures customer data. For a broader overview see Trust.

Authentication

• Email and password sign-in through Supabase Auth, which stores passwords as bcrypt hashes.
• A password chosen at sign-up or reset is checked against Have I Been Pwned's k-anonymity range API; only the first five characters of its SHA-1 hash are sent.
• Sessions use short-lived access tokens that Supabase Auth refreshes automatically.

Authorization

• Postgres Row-Level Security is enabled on every table, so a signed-in user's database requests only reach the workspaces they belong to.
• Server-side work that has no signed-in user — scheduled jobs, webhooks and API-key requests — uses a privileged database key, and is limited to one workspace by the application code.
• Roles (Owner, Bookkeeper, Accountant, Viewer) are checked by the API and by database policies.
• API keys belong to one workspace, are stored only as a hash, and can be revoked at any time.

Transport and storage encryption

• HTTPS only, with HTTP Strict Transport Security (HSTS, preload) on every response.
• The database and file storage are encrypted at rest (AES-256) by our hosting provider, Supabase.
• Platform secrets are kept in Vercel's encrypted environment variables, not in source code.

Application security

• Content-Security-Policy, X-Frame-Options and X-Content-Type-Options headers on every response.
• Customer portal pages send frame-ancestors 'none' so they cannot be framed by another site.
• Request input is validated on the server; most write endpoints use Zod schemas.

Operational security

• Application errors are reported to Sentry.
• GitHub Dependabot checks npm packages and GitHub Actions for updates weekly.

Reporting a vulnerability

Found something? Email security@ddmtech.co.za. We do not currently run a bug-bounty programme but acknowledge and respond to all reports within 48 hours.