Update

apps/supabase/migrations/20251230000001_security_hardening.sql

@@ -0,0 +1,175 @@
+-- Security Hardening Migration
+-- Fixes: Weak invite codes, overly permissive RLS, password settings
+
+-- ============================================
+-- 1. Strengthen invite code generation
+-- Use crypto-secure random with alphanumeric chars (8 chars retained for UX)
+-- ============================================
+
+-- Create a function to generate secure invite codes
+CREATE OR REPLACE FUNCTION generate_secure_invite_code()
+RETURNS TEXT AS $$
+DECLARE
+    chars TEXT := 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789'; -- Removed confusing chars: I, O, 0, 1
+    result TEXT := '';
+    i INTEGER;
+    rand_bytes BYTEA;
+BEGIN
+    -- Get 8 cryptographically secure random bytes
+    rand_bytes := gen_random_bytes(8);
+    
+    FOR i IN 1..8 LOOP
+        result := result || substr(chars, (get_byte(rand_bytes, i-1) % 32) + 1, 1);
+    END LOOP;
+    
+    RETURN result;
+END;
+$$ LANGUAGE plpgsql SECURITY DEFINER;
+
+-- Update the default for new couples to use secure generation
+ALTER TABLE public.couples 
+ALTER COLUMN invite_code SET DEFAULT generate_secure_invite_code();
+
+-- Add rate limiting tracking table for invite code attempts
+CREATE TABLE IF NOT EXISTS public.invite_code_attempts (
+    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    ip_hash TEXT NOT NULL, -- Hashed IP for privacy
+    user_id UUID REFERENCES auth.users(id) ON DELETE CASCADE,
+    attempted_at TIMESTAMPTZ DEFAULT NOW(),
+    was_successful BOOLEAN DEFAULT FALSE
+);
+
+-- Index for efficient rate limiting queries
+CREATE INDEX IF NOT EXISTS idx_invite_attempts_user_time 
+ON public.invite_code_attempts(user_id, attempted_at);
+
+-- Enable RLS on attempts table
+ALTER TABLE public.invite_code_attempts ENABLE ROW LEVEL SECURITY;
+
+-- Only allow inserts from authenticated users
+CREATE POLICY "Authenticated users can log attempts"
+    ON public.invite_code_attempts
+    FOR INSERT
+    WITH CHECK (auth.role() = 'authenticated');
+
+
+-- ============================================
+-- 2. Fix overly permissive couples RLS policy
+-- ============================================
+
+-- Drop the overly permissive policy
+DROP POLICY IF EXISTS "Users can view couple by invite code" ON public.couples;
+
+-- Replace with a more restrictive policy
+-- Users can only view their own couple OR look up a couple via RPC (not direct table access)
+CREATE POLICY "Users can only view their own couple"
+    ON public.couples FOR SELECT
+    USING (
+        id IN (SELECT couple_id FROM public.profiles WHERE id = auth.uid())
+    );
+
+-- Create a secure RPC function for invite code lookup
+-- This only returns success/failure, not couple data
+CREATE OR REPLACE FUNCTION public.verify_invite_code(code TEXT)
+RETURNS JSONB AS $$
+DECLARE
+    couple_record RECORD;
+    member_count INTEGER;
+BEGIN
+    -- Normalize the code
+    code := UPPER(TRIM(code));
+    
+    -- Check if code exists
+    SELECT id INTO couple_record
+    FROM public.couples
+    WHERE UPPER(invite_code) = code;
+    
+    IF couple_record.id IS NULL THEN
+        RETURN jsonb_build_object('valid', false, 'error', 'Invalid invite code');
+    END IF;
+    
+    -- Check member count
+    SELECT COUNT(*) INTO member_count
+    FROM public.profiles
+    WHERE couple_id = couple_record.id;
+    
+    IF member_count >= 2 THEN
+        RETURN jsonb_build_object('valid', false, 'error', 'This couple already has two partners');
+    END IF;
+    
+    RETURN jsonb_build_object('valid', true, 'couple_id', couple_record.id);
+END;
+$$ LANGUAGE plpgsql SECURITY DEFINER;
+
+-- Grant execute permission to authenticated users
+GRANT EXECUTE ON FUNCTION public.verify_invite_code(TEXT) TO authenticated;
+
+
+-- ============================================
+-- 3. Optional: Add password policy comment
+-- (Password length is enforced client-side, but should also be in Supabase Auth config)
+-- ============================================
+
+COMMENT ON SCHEMA public IS 'Password policy: Minimum 8 characters required. Configure in Supabase Dashboard > Auth > Policies';
+
+
+-- ============================================
+-- 4. Protect push tokens from being accessed by other users
+-- Push tokens should only be accessible via service role for notifications
+-- ============================================
+
+-- Create a secure view for partner profile access that excludes sensitive fields
+CREATE OR REPLACE VIEW public.partner_profiles AS
+SELECT 
+    id,
+    name,
+    avatar_url,
+    is_premium,
+    couple_id,
+    created_at,
+    updated_at,
+    show_explicit_content
+    -- Explicitly excluding: push_token
+FROM public.profiles;
+
+-- Allow authenticated users to query the view
+GRANT SELECT ON public.partner_profiles TO authenticated;
+
+-- Add comment explaining the security rationale
+COMMENT ON VIEW public.partner_profiles IS 
+'Secure view of profiles excluding push_token. Use this view when displaying partner information. Push tokens are only accessible via service role for sending notifications.';
+
+-- Create a function to safely get partner info without exposing push_token
+CREATE OR REPLACE FUNCTION public.get_partner_profile()
+RETURNS JSONB AS $$
+DECLARE
+    current_couple_id UUID;
+    partner_data JSONB;
+BEGIN
+    -- Get current user's couple_id
+    SELECT couple_id INTO current_couple_id
+    FROM public.profiles
+    WHERE id = auth.uid();
+    
+    IF current_couple_id IS NULL THEN
+        RETURN NULL;
+    END IF;
+    
+    -- Get partner profile without sensitive fields
+    SELECT jsonb_build_object(
+        'id', p.id,
+        'name', p.name,
+        'avatar_url', p.avatar_url,
+        'is_premium', p.is_premium,
+        'couple_id', p.couple_id,
+        'created_at', p.created_at
+    ) INTO partner_data
+    FROM public.profiles p
+    WHERE p.couple_id = current_couple_id
+    AND p.id != auth.uid();
+    
+    RETURN partner_data;
+END;
+$$ LANGUAGE plpgsql SECURITY DEFINER;
+
+GRANT EXECUTE ON FUNCTION public.get_partner_profile() TO authenticated;