Security

Encryption

• In transit: all traffic between you and the Service is encrypted using HTTPS/TLS. We enforce strict transport security (HSTS).
• At rest: sensitive provider credentials — including the Plaid access tokens that let us refresh your bank connections, and stored third-party authentication tokens — are encrypted at rest using authenticated encryption (AES-256-GCM).

Authentication and passwords

• Passwords are stored using adaptive one-way hashing — never in plain text — and are never logged.
• We enforce a password policy requiring a minimum length and a mix of character types.
• On the web, your session is held in a secure, httpOnly cookie that JavaScript cannot read; native apps store session credentials in secure device storage.
• Changing your password signs out other active sessions, so a password reset doubles as a recovery action.
• We email you when we see a sign-in from a device we do not recognize, so an account takeover is visible to you even if the password held.
• We support sign-in with third-party providers such as Google, Apple, and GitHub.
• Personal access tokens for programmatic access are shown to you once at creation and stored only as a hash, can be given an expiry, and can be revoked at any time from your account settings.

Abuse and bot defense

• Authentication and API endpoints are rate limited per client to slow brute force and abuse.
• Sign-in, sign-up, and password-reset flows use Cloudflare Turnstile for adaptive bot detection. Our risk checks are designed so that your raw email address is not stored or logged.
• On Android, our app can additionally use Google Play Integrity to check that the app and device are genuine before a credential sign-in or sign-up. This attests the app, not you, and never replaces email verification or the checks above.
• Email verification is required before high-trust actions such as connecting a bank or inviting workspace members.

Application and data isolation

• Data is isolated per user and per workspace, enforced at the database layer with row-level security policies.
• Ownership and authorization are verified on the server for sensitive actions, such as disconnecting or deleting a bank.
• We enforce a Content Security Policy and apply hardened HTTP security headers such as X-Frame-Options: DENY and X-Content-Type-Options: nosniff.

Operational practices

• Secrets are managed through environment configuration, never committed to source control, with an automated pre-commit secret scanner.
• Production logging is minimized and scrubbed so that secrets, tokens, and credentials are not written to logs.
• We follow least-privilege principles for access to infrastructure and third-party services.

Reliability and backups

• Your data is stored in managed PostgreSQL databases hosted on Neon, our primary database provider, with encryption in transit and at rest at the infrastructure layer.
• We maintain a separate standby database on Supabase that is kept in sync as part of our disaster-recovery setup, so your data can be restored if the primary database becomes unavailable.
• Database backups and the standby copy are access-controlled and retained only as long as needed for recovery.

Your role in security

Security is a shared responsibility. Please use a strong, unique password, keep your devices secure, be alert to phishing, and only sign in at app.superbasicfinance.com or in our official iOS and Android apps. We will never ask you for your password, a personal access token, or your online banking credentials by email. Notify us immediately if you suspect unauthorized access to your account.

Reporting a vulnerability

We welcome reports from security researchers. If you believe you have found a vulnerability, please email security@superbasicfinance.com with details and steps to reproduce. Please give us a reasonable opportunity to investigate and remediate before any public disclosure, and do not access or modify data that is not yours. We appreciate responsible disclosure and will work with you in good faith.