Security
Last updated: 2026-05-21
Reporting a vulnerability
Email khadinakbaronline@gmail.com with the subject line SECURITY: and a description that lets us reproduce. Please don't open a public GitHub issue for vulnerabilities. We aim to acknowledge within 48 hours.
How we handle credentials
- · Provider API keys are encrypted at rest with AES-256-GCM (envelope key in
TOKENFLEX_VAULT_KEY). - · CLI device tokens are stored only as SHA-256 hashes server-side; the raw token is shown once at create time.
- · Auth sessions ride Supabase's HttpOnly cookies. The refresh token rotates on every request via the proxy middleware.
- · Service-role keys live only in server-side env; they never reach the browser.
Row-level security
Every user-owned Postgres table uses Supabase RLS keyed off auth.uid(). The public profile API explicitly opts back into read access for rows where the profile's privacy_level is public.
What we run
- · Vercel HTTPS-only with HSTS
- · Supabase managed Postgres 17 + Auth in us-east-1
- · Sentry-style error logging on server routes (no request bodies)