Security

Last updated: 2026-05-20

This page describes the practical security measures we take. We are not SOC2-audited yet (we'll get there); the layers below are what we have in place today.

How your data is isolated

Multi-tenant by design. Every business's data is tagged with its company_id. Every database query filters by it.
PostgreSQL Row-Level Security (RLS) is enforced and forced at the database level. Even if a bug in our application code omitted the filter, the database itself would refuse to return another tenant's row.
Restricted database role. The application uses a Postgres role that cannot bypass RLS, even with a misconfigured query.

Account security

Passwords are hashed with bcrypt before storage. We never see your plain password.
Sign-in cookies are HttpOnly, Secure, SameSite=Lax.
Write requests require a CSRF token bound to the session via HMAC.
Sign-in attempts are rate-limited.
Sign in with Google is supported (you can avoid passwords entirely).

Payments and cards

We do not store or process card numbers. All payment data is handled by Stripe, a PCI Level-1 service provider. We receive only a customer reference and the result of each transaction.

Transport & storage

HTTPS everywhere, with HSTS preload.
Strict Content-Security-Policy, X-Frame-Options: DENY, and Referrer-Policy: no-referrer.
Data at rest is encrypted by our hosting providers (Supabase, Render).

Responsible disclosure

If you find a vulnerability, please email us at [email protected] with a clear description and (if possible) reproduction steps. We will acknowledge within 72 hours and work with you in good faith. Please don't publicly disclose until we've fixed it.

Open security debt (in plain sight)

We are still in the pilot stage. We have not completed a third-party security audit yet — that comes once we have meaningful revenue.
Two-factor authentication for account owners is on the roadmap.
Our Content-Security-Policy still allows inline scripts; we are migrating to nonce-based CSP.