Security
Infrastructure
Supabase (PostgreSQL): All user data lives in a Supabase-managed PostgreSQL instance on AWS (ap-south-1 region — Mumbai). Supabase handles encryption at rest (AES-256) and in transit (TLS 1.2+).
Row-Level Security (RLS): Every table with user data has RLS policies. Your data is never retrievable by another user's session — at the database level, not just the application level. This is enforced by Postgres policies, not application code.
Edge Functions: AI calls and credit mutations run in Supabase Edge Functions (Deno runtime, isolate-per-request). No persistent server processes that could be compromised.
Authentication
- Email/password with Supabase Auth (bcrypt hashed passwords, never stored in plaintext)
- Google OAuth (tokens never stored; only the user ID is retained)
- GitHub OAuth (same)
- Session tokens are JWT, signed with the project's JWT secret, 1-hour expiry with refresh
BYOK (Bring Your Own Keys)
If you provide your own AI API keys (Groq or Gemini), they are encrypted with AES-256-GCM before storage using a per-user encryption key. The platform never logs these keys. They are decrypted only within the Edge Function at call time.
API security
- All API calls require a valid JWT
- The Supabase anon key used on the public marketing site (
www.freedomwise.in) has no write permissions and can only read fromv_public_*views - Service role keys are never used on the public site
- CORS is locked to the app domain
Responsible disclosure
Found a vulnerability? Email security@freedomwise.in with details. We aim to respond within 48 hours and resolve critical issues within 7 days.
We don't have a formal bug bounty program yet, but we acknowledge researchers in our changelog and treat reports with the seriousness they deserve.