Skip to content

Security

Operations-side security runbook. Covers the headers layer, where secrets live, how to rotate them, and minimal incident response. Full details on HTTP headers are in docs/SECURITY_HEADERS.md; details on RLS are in docs/architecture/rls.md.

Defense-in-depth layers

  1. Cloudflare edge — TLS termination, WAF rules (dashboard-configured), public/_headers and public/_redirects.
  2. Browser headers (CSP, HSTS, frame-ancestors, etc.) — applied at public/_headers in production only. Dev server does not apply them.
  3. Supabase Auth — JWT-based sessions, refresh token rotation enabled (supabase/config.toml: enable_refresh_token_rotation = true).
  4. RLS — the primary data-layer boundary. Every permission-gated table has an RLS policy that calls auth_user_has_permission('x.y'). See docs/architecture/rls.md.
  5. Application permission checks — <ProtectedRoute requiredPermissions=[...]>, <PermissionGate permission="...">, and await requirePermission('x.y') in src/lib/api.ts. Enforced by the permissions matrix test (see testing.md).
  6. Edge Function auth — either verify_jwt = true (default) or an in-function check (HMAC signature for webhooks, bearer token for internal callers).

Tip

RLS is the real boundary. Application checks are UX (hide buttons) and defence-in-depth. If RLS is wrong, a malicious client can bypass every frontend check by calling Supabase directly.

HTTP security headers

Applied via public/_headers to every route in the Cloudflare Pages deploy:

  • X-Frame-Options: DENY + CSP frame-ancestors 'none'
  • X-Content-Type-Options: nosniff
  • Referrer-Policy: strict-origin-when-cross-origin
  • Permissions-Policy: camera=(), microphone=(), geolocation=(), interest-cohort=()
  • Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  • X-DNS-Prefetch-Control: off
  • Content-Security-Policy — see docs/SECURITY_HEADERS.md for the full directive-by-directive table.

Verifying after a deploy (condensed from the full doc):

  1. Deploy a preview/staging branch.
  2. Open the preview URL; load public site, log in as customer / partner / admin; exercise Google Drive upload and Turnstile.
  3. Devtools → Console → filter for "Content Security Policy". Expect zero violations.
  4. Network tab: confirm Strict-Transport-Security, X-Frame-Options, Content-Security-Policy on the HTML response.
  5. Confirm cache-control: public, max-age=31536000, immutable on /assets/<hash>.js.

Where secrets live

Secret Location Rotation trigger
VITE_* (frontend build) GitHub Actions secrets + Cloudflare Pages env vars Collaborator departure; suspected leak
Supabase service role key Supabase dashboard only; never in frontend On compromise
Edge Function secrets (RESEND_API_KEY, WHATSAPP_*, RAZORPAY_WEBHOOK_SECRET, GOOGLE_DRIVE_*, etc.) Supabase project secrets via supabase secrets set On compromise; on provider-initiated rotation
SUPABASE_DB_URL GitHub Actions secrets (used by the backup workflow) Collaborator with admin access leaves; password change
AWS backup secrets GitHub Actions secrets Standard IAM hygiene

Canonical list: docs/secrets-setup.md.

Danger

Never commit secrets. env.example holds only public values (anon key, Turnstile site key, Google client ID). The anon key is safe in the frontend because RLS enforces per-row access.

Rotating an Edge Function secret

General pattern (applies to every secret set via supabase secrets set):

  1. Generate the new secret at the provider (e.g. rotate the Razorpay webhook secret in the Razorpay dashboard).

  2. Set the new value in Supabase:

    supabase secrets set KEY_NAME=<new-value>

  3. Redeploy the function that reads it (so the new value is loaded into the current instance):

    supabase functions deploy <function-name>

  4. Verify end-to-end with a real request.

  5. Revoke the old secret at the provider only after you have confirmed the new value works.

Rotating the Razorpay webhook secret

The razorpay-webhook Edge Function authenticates each call by recomputing HMAC-SHA256(raw_body, RAZORPAY_WEBHOOK_SECRET) and comparing against X-Razorpay-Signature. The function has verify_jwt = false in supabase/config.toml precisely because it does its own auth against this secret.

  1. In the Razorpay dashboard, open the webhook configuration (Payments → Webhooks → the endpoint pointing at the Supabase Edge Function URL).
  2. Rotate the webhook secret there. Copy the new value.

  3. Update Supabase:

    supabase secrets set RAZORPAY_WEBHOOK_SECRET=<new-value>
supabase functions deploy razorpay-webhook

  4. Trigger a test webhook from Razorpay (the dashboard has a "Send test webhook" option). Watch Supabase dashboard → Edge Functions → razorpay-webhook → Logs — the request should succeed, not return server misconfigured or invalid signature.

  5. After one or two real payment events confirm the new secret is live, confirm the old value is fully deactivated in Razorpay.

Warning

Do not remove the old value before the function is redeployed. The running Edge Function instance caches env vars at startup; until redeploy, it is validating against the old secret. Payments during that window will fail signature validation.

Rotating SUPABASE_DB_URL

Used only by the backup workflow.

  1. In Supabase dashboard → Settings → Database, regenerate the database password.
  2. Compose the new postgres://... URI with the new password (use the Direct connection tab — not pgbouncer).
  3. GitHub: Settings → Secrets and variables → Actions → SUPABASE_DB_URL → Update.
  4. Manually trigger the backup workflow (gh workflow run supabase-backup.yml) and confirm it succeeds.

Incident response

Baseline playbook. This is a stub; expand it as the team runs real incidents and learns specifics.

Suspected secret leak (key in logs, public repo, Slack screenshot)

  1. Rotate the secret immediately. Follow the provider-specific steps above.
  2. Invalidate any sessions if the secret was a Supabase service key: Supabase dashboard → Authentication → Sessions → Revoke all (or per-user).
  3. Notify CEO / GM — they are the only approvers for incident comms and, where required, customer disclosure.
  4. Audit access logs in Supabase dashboard and at the provider (Razorpay, Meta, Google Cloud) for unexpected activity.
  5. Write a post-incident note in the team's ops channel with the timeline and what changed.

Suspicious account activity (impossible travel, brute force, mass data export)

  1. Identify the user via Supabase Auth → Users.
  2. Lock the account: set is_active = false or ban via auth.admin.updateUserById({ banned_until: 'permanent' }).
  3. Revoke all sessions for that user (Supabase Auth → that user → Revoke sessions).
  4. Preserve evidence: export the user's audit trail (activity logs / bookings / finance events) before deleting.
  5. Page CEO / GM. If customer data may have been exfiltrated, CEO decides on disclosure timing per local regulations.

Production data corruption

  1. Page CEO / GM.
  2. Put the app into maintenance mode ().
  3. Assess scope with direct SQL (via SUPABASE_DB_URL) before trying to fix with application code.
  4. If the corruption is recent (< 7 days), prefer Supabase PITR over the nightly artifacts — it has lower RPO. See backup-restore.md.
  5. Post-incident: write a forward migration that prevents the same corruption from recurring (constraint, RLS tightening, application guard).

Routine hygiene

  • Quarterly: rotate any secret whose provider does not auto-rotate (WhatsApp access token, Razorpay webhook secret).
  • Whenever a collaborator with admin access leaves:
    • Remove their GitHub repo access.
    • Remove their Supabase project membership.
    • Rotate SUPABASE_DB_URL and any Edge Function secrets they were exposed to.
    • Rotate Cloudflare Pages deploy credentials if they had dashboard access.
  • Annually: review the CSP allowlist in public/_headers against the actually-loaded third parties. Remove anything the app no longer uses.