Security

Everything in transit between your browser, our edge functions, and our database is TLS 1.2 or higher. We redirect HTTP → HTTPS on the apex domain and on every operator subdomain, and HSTS is enabled with a 1-year max-age.

At rest, Postgres rows and storage buckets are encrypted with AES-256 via the underlying Supabase / cloud-provider managed keys. Secrets in application config (Stripe keys, Xero refresh tokens, service-role tokens) are stored in the Supabase Vault, never in plain-text env files in production.

User authentication is provided by Supabase Auth. We support password login with a strong-password policy and magic-link email login.

Service-to-service authentication uses short-lived JWTs signed by Supabase. The service-role JWT used by scheduled jobs is stored and rotated via the Supabase Vault, never embedded in database settings.

We enforce server-side rate limits on login, signup, password reset, and other high-risk endpoints via a Postgres-backed limiter that survives serverless cold starts; per-user buckets are keyed on authenticated identity, falling back to IP for unauthenticated calls.

Every tenant-scoped table in the database has row-level security (RLS) enabled, with policies that gate every SELECT, INSERT, UPDATE, and DELETE. Isolation is enforced by Postgres on the way out of the database, not by application code, so an app-layer bug cannot leak a tenant’s rows to another tenant.

RLS policies use a small set of SECURITY DEFINER helper functions (e.g. get_user_company_id, is_admin, is_platform_admin) that resolve the caller’s identity. These helpers are stable, parallel-safe, and inlined by the planner so the existing tenant indexes keep working under RLS.

We run a tenant-isolation SQL regression suite in CI that asserts a caller in tenant A cannot read, write, or delete rows owned by tenant B. New tables that store tenant data are required to ship with both the RLS policy and the matching regression test in the same migration.

Our primary database runs on Supabase, hosted in AWS ap-southeast-2 (Sydney). Supabase takes daily backups and provides point-in-time recovery (PITR) snapshots; daily backups are retained for the window documented on our Supabase plan, and PITR lets us roll forward to within minutes of any moment inside the retention window.

Errors and anomalies across the client, the server, and our edge functions are monitored with Sentry, and incidents are tracked in a single internal queue. Service-availability incidents and component status are published on our status page (/resources/status).

For privacy breaches, we comply with the New Zealand Privacy Act 2020: we notify affected parties and the Office of the Privacy Commissioner of notifiable privacy breaches as the Act requires, and we keep affected operators informed until the incident is resolved.

Every production change goes through CI, including the tenant-isolation regression suite described above.

We don’t run a paid bug-bounty program, but we welcome reports from independent security researchers. If you believe you’ve found a vulnerability, please email security@litehq.com with a clear description, reproduction steps, and (if applicable) a proof-of-concept.

Our promises in return:

• We will acknowledge receipt promptly.
• We will keep you informed of the triage and remediation timeline.
• We will credit you publicly (if you want to be credited) once the issue is fixed.
• We will not pursue legal action against good-faith security research that follows the disclosure rules below.

Disclosure rules: do not access data that doesn’t belong to you; do not run automated scanners that materially affect availability for other users; do not publish details before we’ve had a reasonable window to fix (typically 90 days, or sooner by mutual agreement).

Security disclosures, responsible-disclosure questions, and security questionnaires: security@litehq.com.

Privacy and data-rights questions are handled separately on the privacy page.