Security

Tenant isolation

Every table carries a brand and organisation identifier and is protected by PostgreSQL row-level security with FORCE ROW LEVEL SECURITY, so the policies apply even to the table owner.

Isolation is asserted by tests that run on every database reset. If a policy regresses so that one organisation can see another's rows, the assertion fails rather than the leak going unnoticed.

Access tokens

OAuth access and refresh tokens are stored in Supabase Vault, encrypted at rest.

No API route we expose returns a token. There is deliberately no path that can hand one back to a browser, including to the account owner — an endpoint that could would be the single highest-value target in the system.

Disconnecting an account deletes its tokens rather than flagging them inactive.

Authentication

Passwords are hashed with bcrypt by Supabase Auth. We never see or store the plaintext.

OAuth uses PKCE where the provider supports it, and the state parameter is single-use — consumed atomically, so a replayed callback is rejected.

Changing your password requires your current password, even though the underlying platform would allow the change with only an active session.

In transit

HTTPS everywhere, with HSTS including subdomains and preload. A strict Content Security Policy, X-Frame-Options DENY, and no permissions granted for camera, microphone or geolocation.

Reporting a vulnerability

Email hamza@cryptoaccountants.live with "SECURITY" in the subject. We will acknowledge within two working days.

Please give us reasonable time to fix an issue before disclosing it publicly. We will not take legal action against good-faith research that avoids privacy violations, data destruction and service disruption.

What we do not yet claim

We are not SOC 2 or ISO 27001 certified, and we will not imply otherwise. There is no formal bug bounty. If a certification matters to your procurement process, ask us before you commit.