ship-safe 1.0.1 → 3.0.0

package/configs/ship-safeignore-template

@@ -0,0 +1,50 @@
+# .ship-safeignore
+# =================
+# Exclude paths from ship-safe secret scanning.
+# Same syntax as .gitignore — one pattern per line, # for comments.
+#
+# Ship-safe already skips test files by default.
+# Use this file to exclude additional paths that generate false positives.
+#
+# USAGE:
+#   Copy this file to your project root as .ship-safeignore
+#   Then run: npx ship-safe scan .
+
+# ── Examples ──────────────────────────────────────────────────────────────────
+
+# Exclude a specific file
+# config/seed-data.js
+
+# Exclude a directory
+# scripts/fixtures/
+
+# Exclude all files matching a pattern
+# **/*.example.js
+# **/*.sample.*
+
+# Exclude documentation that contains example credentials
+# docs/
+# *.md
+
+# Exclude generated files
+# generated/
+# prisma/migrations/
+
+# Exclude vendor/third-party code not in node_modules
+# vendor/
+# third-party/
+
+# ── Common false positive sources ─────────────────────────────────────────────
+
+# E2E test fixtures (ship-safe skips unit tests but not e2e by default)
+# e2e/
+# cypress/fixtures/
+# playwright/
+
+# Seed data with example values
+# prisma/seed.ts
+# database/seeds/
+
+# Infrastructure-as-code with example configs
+# terraform/examples/
+# .terraform/

package/configs/supabase/rls-templates.sql

@@ -0,0 +1,242 @@
+-- =============================================================================
+-- SUPABASE ROW LEVEL SECURITY (RLS) TEMPLATES
+-- =============================================================================
+--
+-- Copy-paste these policies to secure your Supabase tables.
+--
+-- WHY RLS MATTERS:
+-- Without RLS, anyone with your anon key can read/write ALL data.
+-- 83% of exposed Supabase databases have RLS misconfigurations.
+-- Source: https://byteiota.com/supabase-security-flaw-170-apps-exposed-by-missing-rls/
+--
+-- HOW TO USE:
+-- 1. Enable RLS on your table: ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;
+-- 2. Copy the relevant policy below
+-- 3. Replace 'your_table' with your actual table name
+-- 4. Test with different user contexts
+--
+-- =============================================================================
+
+
+-- =============================================================================
+-- STEP 1: ALWAYS ENABLE RLS FIRST
+-- =============================================================================
+
+-- Enable RLS on a table (REQUIRED before adding policies)
+ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;
+
+-- Force RLS for table owners too (recommended for security)
+ALTER TABLE your_table FORCE ROW LEVEL SECURITY;
+
+
+-- =============================================================================
+-- PATTERN 1: USER OWNS THEIR DATA
+-- =============================================================================
+-- Use when: Each user should only see/edit their own records
+-- Example tables: profiles, settings, user_preferences
+
+-- Users can only SELECT their own rows
+CREATE POLICY "Users can view own data"
+ON your_table
+FOR SELECT
+USING (auth.uid() = user_id);
+
+-- Users can only INSERT rows with their own user_id
+CREATE POLICY "Users can insert own data"
+ON your_table
+FOR INSERT
+WITH CHECK (auth.uid() = user_id);
+
+-- Users can only UPDATE their own rows
+CREATE POLICY "Users can update own data"
+ON your_table
+FOR UPDATE
+USING (auth.uid() = user_id)
+WITH CHECK (auth.uid() = user_id);
+
+-- Users can only DELETE their own rows
+CREATE POLICY "Users can delete own data"
+ON your_table
+FOR DELETE
+USING (auth.uid() = user_id);
+
+-- COMBINED: All operations for own data (simpler but less granular)
+CREATE POLICY "Users manage own data"
+ON your_table
+FOR ALL
+USING (auth.uid() = user_id)
+WITH CHECK (auth.uid() = user_id);
+
+
+-- =============================================================================
+-- PATTERN 2: ORGANIZATION/TEAM BASED ACCESS
+-- =============================================================================
+-- Use when: Users belong to orgs and should see all org data
+-- Example tables: projects, documents, team_settings
+
+-- First, create a helper function to get user's org
+CREATE OR REPLACE FUNCTION get_user_org_id()
+RETURNS UUID AS $$
+  SELECT org_id FROM profiles WHERE id = auth.uid()
+$$ LANGUAGE SQL SECURITY DEFINER;
+
+-- Users can view all data in their organization
+CREATE POLICY "Org members can view org data"
+ON your_table
+FOR SELECT
+USING (org_id = get_user_org_id());
+
+-- Users can insert data into their organization
+CREATE POLICY "Org members can insert org data"
+ON your_table
+FOR INSERT
+WITH CHECK (org_id = get_user_org_id());
+
+-- Only allow updates to org data
+CREATE POLICY "Org members can update org data"
+ON your_table
+FOR UPDATE
+USING (org_id = get_user_org_id())
+WITH CHECK (org_id = get_user_org_id());
+
+
+-- =============================================================================
+-- PATTERN 3: ROLE-BASED ACCESS CONTROL (RBAC)
+-- =============================================================================
+-- Use when: Different users have different permission levels
+-- Example: admin, editor, viewer roles
+
+-- Helper function to check user role
+CREATE OR REPLACE FUNCTION get_user_role()
+RETURNS TEXT AS $$
+  SELECT role FROM profiles WHERE id = auth.uid()
+$$ LANGUAGE SQL SECURITY DEFINER;
+
+-- Anyone authenticated can view (public within app)
+CREATE POLICY "Authenticated users can view"
+ON your_table
+FOR SELECT
+USING (auth.role() = 'authenticated');
+
+-- Only admins and editors can insert
+CREATE POLICY "Admins and editors can insert"
+ON your_table
+FOR INSERT
+WITH CHECK (get_user_role() IN ('admin', 'editor'));
+
+-- Only admins can delete
+CREATE POLICY "Only admins can delete"
+ON your_table
+FOR DELETE
+USING (get_user_role() = 'admin');
+
+
+-- =============================================================================
+-- PATTERN 4: PUBLIC READ, AUTHENTICATED WRITE
+-- =============================================================================
+-- Use when: Content is public but only logged-in users can contribute
+-- Example tables: blog_posts, comments, public_profiles
+
+-- Anyone can read (including anonymous)
+CREATE POLICY "Public read access"
+ON your_table
+FOR SELECT
+USING (true);
+
+-- Only authenticated users can insert
+CREATE POLICY "Authenticated users can insert"
+ON your_table
+FOR INSERT
+WITH CHECK (auth.role() = 'authenticated');
+
+-- Users can only update their own posts
+CREATE POLICY "Users can update own posts"
+ON your_table
+FOR UPDATE
+USING (auth.uid() = author_id)
+WITH CHECK (auth.uid() = author_id);
+
+
+-- =============================================================================
+-- PATTERN 5: PRIVATE BY DEFAULT (Explicit sharing)
+-- =============================================================================
+-- Use when: Data is private unless explicitly shared
+-- Example tables: documents, files with sharing
+
+-- Owner can always access
+CREATE POLICY "Owner full access"
+ON documents
+FOR ALL
+USING (auth.uid() = owner_id)
+WITH CHECK (auth.uid() = owner_id);
+
+-- Shared users can view (requires a shares table)
+CREATE POLICY "Shared users can view"
+ON documents
+FOR SELECT
+USING (
+  auth.uid() = owner_id
+  OR
+  EXISTS (
+    SELECT 1 FROM document_shares
+    WHERE document_shares.document_id = documents.id
+    AND document_shares.user_id = auth.uid()
+  )
+);
+
+
+-- =============================================================================
+-- PATTERN 6: TIME-BASED ACCESS
+-- =============================================================================
+-- Use when: Content has publish dates or expiration
+-- Example tables: scheduled_posts, limited_offers
+
+-- Only show published content
+CREATE POLICY "Show only published content"
+ON posts
+FOR SELECT
+USING (
+  published_at IS NOT NULL
+  AND published_at <= NOW()
+  AND (expires_at IS NULL OR expires_at > NOW())
+);
+
+-- Authors can always see their drafts
+CREATE POLICY "Authors see own drafts"
+ON posts
+FOR SELECT
+USING (auth.uid() = author_id);
+
+
+-- =============================================================================
+-- ANTI-PATTERNS: DON'T DO THIS
+-- =============================================================================
+
+-- BAD: Allows anyone to read everything
+-- CREATE POLICY "bad_policy" ON users FOR SELECT USING (true);
+
+-- BAD: No WITH CHECK means users could insert data for other users
+-- CREATE POLICY "bad_insert" ON posts FOR INSERT WITH CHECK (true);
+
+-- BAD: Missing USING clause on UPDATE allows updating any row
+-- CREATE POLICY "bad_update" ON posts FOR UPDATE WITH CHECK (auth.uid() = user_id);
+
+
+-- =============================================================================
+-- TESTING YOUR POLICIES
+-- =============================================================================
+
+-- Test as a specific user (in SQL editor)
+-- SET request.jwt.claim.sub = 'user-uuid-here';
+-- SELECT * FROM your_table;
+
+-- Check existing policies on a table
+SELECT * FROM pg_policies WHERE tablename = 'your_table';
+
+-- List all tables without RLS enabled (DANGER!)
+SELECT schemaname, tablename
+FROM pg_tables
+WHERE schemaname = 'public'
+AND tablename NOT IN (
+  SELECT tablename FROM pg_policies
+);

package/configs/supabase/secure-client.ts

@@ -0,0 +1,225 @@
+/**
+ * Supabase Secure Client Configuration
+ * =====================================
+ *
+ * Copy this file to your project and customize for your needs.
+ *
+ * WHY THIS MATTERS:
+ * - Separates anon (public) and service_role (admin) clients
+ * - Adds type safety for environment variables
+ * - Includes helpers for common secure patterns
+ *
+ * USAGE:
+ *   // In client components (React, Vue, etc.)
+ *   import { supabase } from '@/lib/supabase';
+ *
+ *   // In server-side code (API routes, server components)
+ *   import { supabaseAdmin } from '@/lib/supabase';
+ */
+
+import { createClient, SupabaseClient } from '@supabase/supabase-js';
+
+// =============================================================================
+// ENVIRONMENT VARIABLE VALIDATION
+// =============================================================================
+
+/**
+ * Validates that required environment variables are set.
+ * Call this at app startup to fail fast if misconfigured.
+ */
+function validateEnv() {
+  const required = ['NEXT_PUBLIC_SUPABASE_URL', 'NEXT_PUBLIC_SUPABASE_ANON_KEY'];
+
+  for (const key of required) {
+    if (!process.env[key]) {
+      throw new Error(
+        `Missing required environment variable: ${key}\n` +
+        `Add it to your .env.local file.`
+      );
+    }
+  }
+}
+
+// Validate on module load (comment out if causing issues in edge runtime)
+// validateEnv();
+
+// =============================================================================
+// SUPABASE URL AND KEYS
+// =============================================================================
+
+const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL!;
+const supabaseAnonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!;
+
+// Service role key - ONLY available server-side
+// This key bypasses RLS and should NEVER be exposed to the client
+const supabaseServiceRoleKey = process.env.SUPABASE_SERVICE_ROLE_KEY;
+
+// =============================================================================
+// CLIENT-SIDE SUPABASE CLIENT (uses anon key)
+// =============================================================================
+
+/**
+ * Public Supabase client for use in browser/client components.
+ *
+ * SECURITY NOTES:
+ * - Uses the anon key (safe to expose)
+ * - All operations are subject to RLS policies
+ * - User must be authenticated for protected operations
+ */
+export const supabase = createClient(supabaseUrl, supabaseAnonKey, {
+  auth: {
+    // Persist sessions in localStorage
+    persistSession: true,
+    // Automatically refresh tokens
+    autoRefreshToken: true,
+    // Detect session from URL (for OAuth callbacks)
+    detectSessionInUrl: true,
+  },
+});
+
+// =============================================================================
+// SERVER-SIDE SUPABASE CLIENT (uses service_role key)
+// =============================================================================
+
+/**
+ * Admin Supabase client for use in server-side code ONLY.
+ *
+ * SECURITY NOTES:
+ * - Uses the service_role key (NEVER expose to client)
+ * - Bypasses ALL Row Level Security policies
+ * - Use only in: API routes, server actions, cron jobs
+ * - Always validate user permissions before using
+ *
+ * WHEN TO USE:
+ * - Admin operations (deleting users, bulk updates)
+ * - Background jobs that need full database access
+ * - Webhooks from external services
+ *
+ * WHEN NOT TO USE:
+ * - Any client-side code
+ * - Operations where user context matters
+ * - When RLS should apply
+ */
+export const supabaseAdmin: SupabaseClient | null = supabaseServiceRoleKey
+  ? createClient(supabaseUrl, supabaseServiceRoleKey, {
+      auth: {
+        // Don't persist sessions for admin client
+        persistSession: false,
+        autoRefreshToken: false,
+      },
+    })
+  : null;
+
+/**
+ * Get admin client with error if not configured.
+ * Use this when service_role key is required.
+ */
+export function getSupabaseAdmin(): SupabaseClient {
+  if (!supabaseAdmin) {
+    throw new Error(
+      'SUPABASE_SERVICE_ROLE_KEY is not configured.\n' +
+      'This operation requires admin privileges.'
+    );
+  }
+  return supabaseAdmin;
+}
+
+// =============================================================================
+// HELPER: SERVER-SIDE CLIENT WITH USER CONTEXT
+// =============================================================================
+
+/**
+ * Creates a Supabase client that acts as a specific user.
+ * Useful for server-side operations that should respect RLS.
+ *
+ * @param accessToken - The user's JWT access token
+ * @returns Supabase client authenticated as the user
+ *
+ * USAGE:
+ *   // In API route or server action
+ *   const token = request.headers.get('Authorization')?.replace('Bearer ', '');
+ *   const userClient = createUserClient(token);
+ *   const { data } = await userClient.from('posts').select('*');
+ *   // This respects RLS - user only sees their allowed data
+ */
+export function createUserClient(accessToken: string): SupabaseClient {
+  return createClient(supabaseUrl, supabaseAnonKey, {
+    global: {
+      headers: {
+        Authorization: `Bearer ${accessToken}`,
+      },
+    },
+    auth: {
+      persistSession: false,
+      autoRefreshToken: false,
+    },
+  });
+}
+
+// =============================================================================
+// HELPER: VALIDATE USER BEFORE ADMIN OPERATIONS
+// =============================================================================
+
+/**
+ * Validates that the current user has permission before admin operations.
+ * Always use this before using supabaseAdmin for user-triggered actions.
+ *
+ * @param userId - The user's ID to check
+ * @param requiredRole - The minimum role required (e.g., 'admin')
+ * @returns True if user has permission
+ *
+ * USAGE:
+ *   const hasPermission = await validateUserPermission(userId, 'admin');
+ *   if (!hasPermission) {
+ *     return new Response('Forbidden', { status: 403 });
+ *   }
+ *   // Now safe to use supabaseAdmin
+ */
+export async function validateUserPermission(
+  userId: string,
+  requiredRole: string
+): Promise<boolean> {
+  const admin = getSupabaseAdmin();
+
+  const { data: profile } = await admin
+    .from('profiles')
+    .select('role')
+    .eq('id', userId)
+    .single();
+
+  if (!profile) return false;
+
+  // Customize this based on your role hierarchy
+  const roleHierarchy: Record<string, number> = {
+    viewer: 0,
+    editor: 1,
+    admin: 2,
+    super_admin: 3,
+  };
+
+  const userRoleLevel = roleHierarchy[profile.role] ?? 0;
+  const requiredRoleLevel = roleHierarchy[requiredRole] ?? 999;
+
+  return userRoleLevel >= requiredRoleLevel;
+}
+
+// =============================================================================
+// TYPE DEFINITIONS (customize for your database)
+// =============================================================================
+
+/**
+ * Generate types with:
+ * npx supabase gen types typescript --project-id your-project > types/database.ts
+ *
+ * Then import and use:
+ * import { Database } from '@/types/database';
+ * const supabase = createClient<Database>(url, key);
+ */
+
+// Example type for user profiles
+export interface Profile {
+  id: string;
+  email: string;
+  role: 'viewer' | 'editor' | 'admin';
+  created_at: string;
+}