Skip to main content

Hardcoded credentials & committed secrets

Several credential-handling issues, each a must-fix:

  1. invite-user sets tempPassword = "password" for every newly-created user (auth.admin.createUser({ email_confirm: true })) and returns the temp password in the HTTP response (the UI displays it to copy). Predictable password + email auto-confirmed = trivially takeover-able new accounts.

  2. seed-test-data has zero authentication. It uses the service-role key directly and creates a known-credential super admin ([email protected] / test123456) plus demo cases with access_password = "demo1234". If this function is deployed to production, it is a full account-creation backdoor. It must be excluded from any non-dev deploy.

  3. Committed Supabase secrets. .env ships a live project ref (abpzzrrlaxfdcqndmguk) and the anon key, committed to the repo. The anon key is public-by-design, but the live project is now identifiable and reachable — combined with the public companies read and seed-test-data, the live PoC backend is exposed.

  4. invite-user scans the full user list (auth.admin.listUsers(), O(n)) to find an existing user — not a security hole per se, but won't scale and can leak timing.

Rebuild implication​

Invites use a one-time email link or a random, never-returned password; auto-confirm off. Seed/dev tooling is compile-excluded from production and never service-role-open on a public endpoint. Rotate the committed Supabase project's keys and stop committing .env. Look up users by indexed email, not a full scan.