auth-security-review

name	auth-security-review
description	Use when reviewing or changing ERTZU authentication, authorization, roles, admin behavior, RLS, privacy, blocked-user handling, or sensitive user data flows.

Auth Security Review

When To Use

Use this skill for login/signup, Supabase sessions, profile data, admin actions, blocked users, RLS policies, authenticated route handlers, email recipients, shipping addresses, and any private data exposure.

ERTZU-Specific Instructions

• Supabase Auth is the identity provider.
• profiles.is_admin is the admin marker, but server/RLS/RPC checks must enforce sensitive actions.
• Blocked users must not perform protected marketplace actions.
• Client-side hiding is not authorization.
• Keep private profile data, shipping addresses, payment IDs, and email addresses scoped to participants or admins.

Files And Areas To Inspect

• src/lib/supabase.ts
• src/lib/supabase-server.ts
• src/app/login/page.tsx
• src/app/signup/page.tsx
• src/app/auth/callback/route.ts
• src/app/profile/page.tsx
• src/app/admin/page.tsx
• src/app/api/email/route.ts
• src/app/api/stripe/route.ts
• supabase/schema.sql
• supabase/schema-v8.sql
• supabase/schema-v9.sql
• supabase/schema-v15-security-hardening.sql
• supabase/schema-v17-bid-decisions-payment.sql

Concrete Checks

• Verify route handlers use cookie/session-aware Supabase clients before trusting the caller.
• Verify admin actions are protected by RPC or RLS, not just frontend is_admin.
• Verify public profile access uses safe public fields only.
• Verify public_profiles or other exposed views do not bypass RLS unexpectedly.
• Verify SUPABASE_SECRET_KEY is used only in server-only code.
• Verify email route derives recipients from database records, not client-controlled addresses.
• Verify shipping addresses are visible only to required participants/admins.
• Verify blocked-user checks exist in marketplace RPCs and admin RPCs.
• Verify callback redirects allow only safe relative destinations.

Mistakes To Avoid

• Do not expose service-role or secret keys to Client Components.
• Do not authorize from user-editable metadata.
• Do not trust client-provided role, recipient, price, order, or payment fields.
• Do not grant broad table updates when column-specific grants are sufficient.
• Do not make a public view of private profile fields.
• Do not log emails, addresses, payment IDs, or raw auth/session data unnecessarily.