Trust center
Security model
Designed for less sensitive access
The beta uses manual data and CSV. We never request bank logins, provider passwords, OAuth tokens, private keys or seed phrases.
Account protection
- Invitation-only account creation and verified email.
- Strong password validation and one-way Django password hashing.
- HTTP-only, same-site server sessions and CSRF protection.
- Financial screens require an accepted invitation and active billing entitlement.
- Password reset links are time-limited and single-purpose.
Data isolation
Every finance entity is designed to belong to one internal user. Webhook entitlements use internal user and invitation IDs; billing email alone is never trusted to grant access.
Payment boundary
Dodo Payments hosts checkout. A browser success return cannot activate the product. Only a signed, idempotently processed subscription webhook changes entitlement state.
Browser and PWA boundary
Authenticated responses use no-store. The service worker caches only versioned static assets and an offline explanation page, never financial records, exports or authenticated HTML.
Operational controls
Production deployment uses a dedicated container, database, private Docker network, environment secrets and a loopback-only application port. Health checks expose only service status.
Responsible reporting
If you believe you found a vulnerability, do not access other users’ data. Send reproduction steps to [email protected]. Do not include real financial exports or credentials.
Optional TOTP, encrypted backup operations and external security monitoring are production gates, not claims about the current local prototype.