Security
Tuesday's security posture starts with an architectural choice: hold as little of your data as possible. The less we store, the less there is to breach.
Local-first minimization
Without an account, your financial numbers never leave your browser. With an account, we store exactly one planner profile per user — no bank credentials, no account numbers, no linked institutions, no documents. Tuesday has no connection to your real financial accounts.
Transport and browser protections
- All traffic is HTTPS, with HSTS (including preload) so browsers refuse downgraded connections.
- A strict Content-Security-Policy — no inline scripts, scripts only from our own origin, connections only to our own backend — sharply limits what injected code could ever do.
X-Frame-Options: DENYand companion headers block clickjacking and MIME sniffing.
Backend
- Data is stored in Postgres (Supabase) with row-level security: the database itself enforces that a session can only read or write its own row, even if application code had a bug.
- Authentication (OAuth, magic links, hashed passwords) is handled by Supabase's auth service; Tuesday never sees passwords.
- Server-side functions verify your identity on every call; secrets live in the platform's secret store, never in client code.
Payments
Card data is handled entirely by Stripe (PCI DSS Level 1). Our servers receive webhook confirmations, not card numbers.
Monitoring
Client errors are reported to a private log so failures are visible and fixed; the build pipeline runs automated tests, artifact smoke checks, and header checks on every change before deploy.
Reporting a vulnerability
Found something? Please email security@tuesday.money — we read every report and will respond promptly. Please don't test against other users' data.