openhack 0.1.0__py3-none-any.whl

openhack/prompts/supabase/auth_tokens.py

@@ -0,0 +1,131 @@
+"""
+Supabase Auth, JWT, and service_role key exposure detection prompt.
+"""
+
+SUPABASE_AUTH_PROMPT = """## Auth & JWT Security in Supabase
+
+### Pre-Computed Recon Available
+
+The `supabase_recon` context already contains:
+- `supabase_recon.clients` -- all Supabase client initializations with `uses_service_role` flag
+- `supabase_recon.config.env_vars` -- Supabase-related environment variable names found in the codebase
+- `supabase_recon.edge_functions` -- Edge Functions with `uses_service_role` flag
+
+**Immediate critical findings:**
+- Any entry in `clients` with `uses_service_role: True` in a client-side file (e.g., under `app/`, `pages/`, `components/`, or any file imported by client code)
+- `NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY` in `config.env_vars` (service role key exposed to browser via Next.js public env var)
+
+### What to Look For
+
+1. **service_role key exposed in client code**
+   - The `service_role` key bypasses ALL RLS policies -- it's the master key
+   - Must NEVER appear in client-side code, browser bundles, or public env vars
+   - Check: `NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY`, `VITE_SUPABASE_SERVICE_ROLE_KEY`
+   - Check: `createClient(url, serviceRoleKey)` in files served to the browser
+
+2. **Hardcoded keys in source code**
+   - API keys, service role keys, or JWT secrets committed to the repository
+   - `grep` for long base64 strings near Supabase client initialization
+   - Check `.env.local`, `.env.example`, `.env` files for real key values
+
+3. **getSession() vs getUser() confusion**
+   - `getSession()` reads the session from local storage -- it is NOT authenticated by the server
+   - An attacker can forge the session in localStorage and `getSession()` will trust it
+   - `getUser()` makes a server call to verify the JWT -- this is the safe method
+   - Server-side code should always use `getUser()` for authorization decisions
+
+4. **JWT stored in localStorage**
+   - Tokens in localStorage are accessible to any JavaScript on the page (XSS-exfiltrable)
+   - Supabase stores tokens in localStorage by default
+   - If the app has any XSS vulnerability, auth tokens can be stolen
+
+5. **Missing audience/issuer verification**
+   - Custom endpoints that accept JWTs should verify `iss` (issuer) and `aud` (audience)
+   - Tokens from one Supabase project should not work on another
+   - Edge Functions should not trust the `Authorization` header without verification
+
+6. **apikey treated as identity**
+   - The `apikey` header identifies the project, NOT the user
+   - The anon key is public and project-scoped
+   - Code that checks for `apikey` presence as an auth mechanism is vulnerable
+
+7. **Refresh token mismanagement**
+   - Long-lived refresh tokens that never expire
+   - Refresh tokens not rotated after use
+   - Revocation not implemented for compromised tokens
+
+### Vulnerable Patterns
+
+```typescript
+// VULNERABLE: service_role key in client-side code
+import { createClient } from '@supabase/supabase-js'
+const supabase = createClient(
+  process.env.NEXT_PUBLIC_SUPABASE_URL!,
+  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY!  // EXPOSED TO BROWSER!
+)
+```
+
+```typescript
+// VULNERABLE: Using getSession() for authorization
+export async function GET() {
+  const { data: { session } } = await supabase.auth.getSession()
+  if (!session) return new Response('Unauthorized', { status: 401 })
+  // session could be forged from localStorage!
+  const userId = session.user.id  // CANNOT BE TRUSTED
+  const data = await supabase.from('orders').select().eq('user_id', userId)
+  return Response.json(data)
+}
+```
+
+```typescript
+// VULNERABLE: Treating apikey as authentication
+export async function middleware(req) {
+  const apiKey = req.headers.get('apikey')
+  if (!apiKey) return new Response('Unauthorized', { status: 401 })
+  // apikey is public! This is NOT authentication
+}
+```
+
+### Safe Patterns
+
+```typescript
+// SAFE: service_role key only in server-side code
+// lib/supabase/admin.ts (never imported by client code)
+import { createClient } from '@supabase/supabase-js'
+export const supabaseAdmin = createClient(
+  process.env.SUPABASE_URL!,           // No NEXT_PUBLIC_ prefix
+  process.env.SUPABASE_SERVICE_ROLE_KEY! // No NEXT_PUBLIC_ prefix
+)
+```
+
+```typescript
+// SAFE: Using getUser() for authorization
+export async function GET() {
+  const { data: { user }, error } = await supabase.auth.getUser()
+  if (error || !user) return new Response('Unauthorized', { status: 401 })
+  // user.id is verified by the server
+  const data = await supabase.from('orders').select().eq('user_id', user.id)
+  return Response.json(data)
+}
+```
+
+### Search Patterns
+
+1. Check `supabase_recon.clients` for `uses_service_role: True` -- inspect the file path to determine if client-side
+2. Check `supabase_recon.config.env_vars` for `NEXT_PUBLIC_*SERVICE_ROLE*` or `VITE_*SERVICE_ROLE*`
+3. `grep` for `service_role`, `serviceRole`, `SUPABASE_SERVICE_ROLE` in all files
+4. `grep` for `getSession` in server-side files (API routes, server components, middleware) -- should be `getUser`
+5. `grep` for `localStorage` near token storage/retrieval
+6. `grep` for hardcoded JWT-like strings (long base64 with dots: `eyJ...`)
+7. Check `.env*` files for real key values committed to repo
+
+### Severity Assessment
+
+- **Critical**: service_role key exposed in client bundle or public env var
+- **Critical**: Hardcoded service_role key in committed source code
+- **High**: Using `getSession()` instead of `getUser()` for server-side authorization
+- **High**: Custom endpoints accepting JWTs without audience/issuer verification
+- **Medium**: JWT tokens stored in localStorage (XSS risk)
+- **Medium**: apikey header used as authentication mechanism
+- **Low**: Refresh token configuration concerns
+"""

openhack/prompts/supabase/edge_functions.py

@@ -0,0 +1,150 @@
+"""
+Supabase Edge Functions security detection prompt.
+"""
+
+SUPABASE_EDGE_FUNCTIONS_PROMPT = """## Edge Functions Security in Supabase
+
+### Pre-Computed Recon Available
+
+The `supabase_recon` context already contains:
+- `supabase_recon.edge_functions` -- all discovered Edge Functions with `uses_service_role`, `has_cors`, `has_auth_check`, `has_jwt_verification` flags
+
+**Immediate findings: any Edge Function with `uses_service_role: True` + `has_auth_check: False` is high risk -- it has full database access but doesn't verify who's calling it.**
+
+### What to Look For
+
+1. **service_role usage without JWT verification**
+   - Edge Functions commonly initialize Supabase with `SUPABASE_SERVICE_ROLE_KEY` for admin operations
+   - If the function doesn't verify the caller's JWT, anyone can trigger admin-level database operations
+   - The function must extract and verify the JWT from the `Authorization` header
+
+2. **CORS misconfiguration**
+   - Wildcard `Access-Control-Allow-Origin: *` combined with `Access-Control-Allow-Credentials: true`
+   - Reflected `Origin` header in `Access-Control-Allow-Origin` without validation
+   - Missing CORS headers allowing any origin to call the function
+
+3. **SSRF via fetch()**
+   - Edge Functions can make outbound HTTP requests
+   - If the URL is controlled by user input, the function can be used to probe internal services
+   - Metadata service access: `http://169.254.169.254/` or cloud provider metadata endpoints
+
+4. **Secrets in error traces or logs**
+   - Error responses that include stack traces with environment variable values
+   - `console.log` or `console.error` dumping request/response bodies containing secrets
+   - Service role key or other secrets appearing in response bodies on error
+
+5. **Not re-deriving user from JWT**
+   - Trusting `user_id` or `tenant_id` from the request body instead of extracting from JWT
+   - The function should parse the JWT to get the authenticated user identity
+
+6. **Missing auth on function invocation**
+   - Edge Functions accessible without any Authorization header
+   - No validation that the caller is authenticated at all
+
+### Vulnerable Patterns
+
+```typescript
+// supabase/functions/process-order/index.ts
+// VULNERABLE: service_role with no auth check
+import { createClient } from 'https://esm.sh/@supabase/supabase-js@2'
+
+Deno.serve(async (req) => {
+  const { orderId, userId } = await req.json()
+
+  // Uses service_role (bypasses all RLS)
+  const supabase = createClient(
+    Deno.env.get('SUPABASE_URL')!,
+    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
+  )
+
+  // Trusts client-supplied userId instead of extracting from JWT
+  const { data } = await supabase
+    .from('orders')
+    .update({ status: 'processed' })
+    .eq('id', orderId)
+    .eq('user_id', userId)  // Client controls this!
+
+  return new Response(JSON.stringify(data))
+})
+```
+
+```typescript
+// VULNERABLE: Wildcard CORS with credentials
+const corsHeaders = {
+  'Access-Control-Allow-Origin': '*',
+  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
+  'Access-Control-Allow-Credentials': 'true',  // Dangerous with wildcard origin!
+}
+```
+
+```typescript
+// VULNERABLE: SSRF via user-controlled URL
+Deno.serve(async (req) => {
+  const { webhookUrl, data } = await req.json()
+  const response = await fetch(webhookUrl, {  // User controls the URL!
+    method: 'POST',
+    body: JSON.stringify(data),
+  })
+  return new Response(JSON.stringify({ status: response.status }))
+})
+```
+
+### Safe Patterns
+
+```typescript
+// SAFE: Verify JWT before using service_role
+import { createClient } from 'https://esm.sh/@supabase/supabase-js@2'
+
+Deno.serve(async (req) => {
+  // Verify the caller's JWT
+  const authHeader = req.headers.get('Authorization')
+  if (!authHeader) {
+    return new Response('Missing authorization', { status: 401 })
+  }
+
+  // Create a user-context client to verify the token
+  const supabaseUser = createClient(
+    Deno.env.get('SUPABASE_URL')!,
+    Deno.env.get('SUPABASE_ANON_KEY')!,
+    { global: { headers: { Authorization: authHeader } } }
+  )
+
+  const { data: { user }, error } = await supabaseUser.auth.getUser()
+  if (error || !user) {
+    return new Response('Invalid token', { status: 401 })
+  }
+
+  // Now use service_role for admin operations, scoped to verified user
+  const supabaseAdmin = createClient(
+    Deno.env.get('SUPABASE_URL')!,
+    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
+  )
+
+  const { data } = await supabaseAdmin
+    .from('orders')
+    .update({ status: 'processed' })
+    .eq('user_id', user.id)  // user.id from verified JWT
+
+  return new Response(JSON.stringify(data))
+})
+```
+
+### Search Patterns
+
+1. Check `supabase_recon.edge_functions` for `uses_service_role: True` + `has_auth_check: False`
+2. Read each Edge Function file (`supabase/functions/*/index.ts`)
+3. `grep` for `SUPABASE_SERVICE_ROLE_KEY`, `Deno.env.get`, `createClient`
+4. `grep` for `Access-Control-Allow-Origin` and CORS patterns
+5. `grep` for `fetch(` with dynamic URLs (SSRF risk)
+6. Check for `Authorization` header extraction and JWT verification
+7. Look for `req.json()` fields used directly as user identity
+
+### Severity Assessment
+
+- **Critical**: Edge Function with service_role and no auth, performing data mutations
+- **High**: Edge Function trusting client-supplied user IDs with service_role
+- **High**: SSRF via user-controlled fetch URLs
+- **Medium**: CORS wildcard with credentials
+- **Medium**: Secrets leaked in error responses
+- **Low**: Missing rate limiting on function invocation
+"""

openhack/prompts/supabase/graphql.py

@@ -0,0 +1,102 @@
+"""
+Supabase GraphQL security detection prompt.
+"""
+
+SUPABASE_GRAPHQL_PROMPT = """## GraphQL Security in Supabase
+
+### Pre-Computed Recon Available
+
+The `supabase_recon` context already contains:
+- `supabase_recon.graphql.introspection_enabled` -- whether introspection queries succeed as anon
+- `supabase_recon.graphql.types_count` -- number of types exposed
+- `supabase_recon.schema` -- PostgREST schema (compare with GraphQL for parity drift)
+
+**Key insight: Supabase GraphQL (pg_graphql) sits on top of Postgres with RLS. However, enforcement can drift between REST and GraphQL paths, and nested queries can expose data that direct queries wouldn't.**
+
+### What to Look For
+
+1. **Introspection enabled in production**
+   - Introspection queries reveal the entire schema: tables, columns, types, relations
+   - Check `supabase_recon.graphql.introspection_enabled`
+   - While Supabase enables this by default, it exposes the attack surface
+
+2. **Nested relation queries bypassing per-row checks**
+   - GraphQL allows deep nesting: `{ users { orders { payments { ... } } } }`
+   - RLS is applied per-table, but nested resolvers may not re-check ownership at each level
+   - If `users` has RLS but `orders` doesn't, querying through `users->orders` may leak order data
+
+3. **Global node IDs reusable across viewers**
+   - pg_graphql provides global `nodeId` fields for relay-style pagination
+   - If one user discovers a `nodeId`, they might query it directly as a different user
+   - The `nodeId` encodes table and primary key, allowing targeted access
+
+4. **REST vs GraphQL enforcement drift**
+   - Protections applied at the REST/PostgREST level may not exist in the GraphQL path
+   - Column restrictions, computed fields, or custom logic may differ between the two
+   - Test the same query via both REST and GraphQL to check parity
+
+5. **Deep nesting for resource exhaustion**
+   - Deeply nested queries can cause expensive joins
+   - No built-in query depth limiting in pg_graphql
+
+### Vulnerable Patterns
+
+```graphql
+# VULNERABLE: Introspection reveals full schema
+{
+  __schema {
+    types {
+      name
+      fields {
+        name
+        type { name }
+      }
+    }
+  }
+}
+```
+
+```graphql
+# VULNERABLE: Deep nested query may bypass per-row checks
+{
+  usersCollection {
+    edges {
+      node {
+        email
+        ordersCollection {
+          edges {
+            node {
+              amount
+              paymentsCollection {
+                edges {
+                  node {
+                    cardLast4
+                    billingAddress
+                  }
+                }
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+### Search Patterns
+
+1. Check `supabase_recon.graphql.introspection_enabled` for immediate finding
+2. `grep` app code for `graphql`, `/graphql/v1`, `gql` template tags
+3. Compare `supabase_recon.schema.tables` (REST) with GraphQL introspection types
+4. Look for nested query patterns in application code
+5. For targeted probing: use `supabase_graphql_query` with deep nested queries on tables that have RLS gaps
+
+### Severity Assessment
+
+- **Critical**: Nested GraphQL queries expose sensitive data that REST + RLS would block
+- **High**: REST vs GraphQL enforcement drift allowing bypass via GraphQL path
+- **Medium**: Introspection enabled revealing sensitive schema structure
+- **Medium**: Global node IDs allowing cross-user targeted access
+- **Low**: Deep nesting without depth limits (DoS potential)
+"""

openhack/prompts/supabase/postgrest.py

@@ -0,0 +1,99 @@
+"""
+Supabase PostgREST and REST API vulnerability detection prompt.
+"""
+
+SUPABASE_POSTGREST_PROMPT = """## PostgREST / REST API Vulnerabilities in Supabase
+
+### Pre-Computed Recon Available
+
+The `supabase_recon` context already contains:
+- `supabase_recon.anon_access` -- which tables the anon role can SELECT/INSERT/UPDATE/DELETE
+- `supabase_recon.schema.columns` -- column names per table (from OpenAPI spec)
+- `supabase_recon.schema.tables` -- all tables exposed via PostgREST
+
+**Start by reviewing `anon_access` for tables with unexpected access permissions.** Any table where anon can read or write is a potential finding.
+
+### What to Look For
+
+1. **IDOR via direct row access**
+   - Tables accessible by anon where rows can be fetched by ID
+   - No ownership filter means any row is accessible: `/rest/v1/orders?id=eq.<any_id>`
+   - Check if `supabase_recon.query_patterns` shows `.from('table').select()` without `.eq('user_id', ...)`
+
+2. **Filter abuse for data extraction**
+   - `or` filters: `?or=(user_id.eq.X,user_id.is.null)` to bypass intended scoping
+   - `ilike` filters: `?email=ilike.*@company.com` for wildcard enumeration
+   - `neq` filters: `?role=neq.admin` to probe for admin rows
+   - Combine filters to extract data column by column
+
+3. **Relation embedding overfetch**
+   - PostgREST allows embedding related tables: `?select=*,profile(*),orders(*)`
+   - If the parent table has RLS but the embedded table doesn't, data leaks through the join
+   - Check for foreign key relationships between protected and unprotected tables
+
+4. **Mass assignment via PATCH/POST**
+   - If anon or authenticated users can INSERT/UPDATE, they may modify unintended columns
+   - Example: setting `role`, `is_admin`, `org_id` via PATCH when only `name` was intended
+   - Check if the app uses RPC functions for writes instead of direct table access
+
+5. **Count-based blind enumeration**
+   - `Prefer: count=exact` header returns total row count even with `limit=0`
+   - Can enumerate total records in a table without reading actual data
+   - Use `supabase_query_table` with `count: "exact"` to test
+
+6. **Schema exposure**
+   - PostgREST OpenAPI spec reveals table names, column names, types, and foreign keys
+   - `supabase_recon.schema` already has this data -- check for sensitive column names
+
+### Vulnerable Application Code Patterns
+
+```typescript
+// VULNERABLE: No ownership filter, any user can read all orders
+const { data } = await supabase
+  .from('orders')
+  .select('*')
+
+// VULNERABLE: Client-controlled filter that can be bypassed
+const { data } = await supabase
+  .from('users')
+  .select('*')
+  .eq('id', params.id)  // User controls the ID
+```
+
+```typescript
+// VULNERABLE: Embedding exposes related data
+const { data } = await supabase
+  .from('posts')
+  .select('*, author:users(*), comments(*)')
+  // If users table has weaker RLS than posts, author data leaks
+```
+
+### Safe Patterns
+
+```typescript
+// SAFE: Server-side ownership filter using authenticated user
+const { data: { user } } = await supabase.auth.getUser()
+const { data } = await supabase
+  .from('orders')
+  .select('*')
+  .eq('user_id', user.id)
+```
+
+### Search Patterns
+
+1. Check `supabase_recon.anon_access` for tables with `select: True` or `insert: True`
+2. Check `supabase_recon.schema.columns` for sensitive column names (email, password, ssn, token, secret)
+3. `grep` app code for `.from(` calls without subsequent `.eq('user_id'` or ownership filters
+4. Look for `select('*,` patterns that embed related tables
+5. For targeted probing: use `supabase_query_table` with filter combinations to test data extraction
+6. For write testing: use `supabase_mutate_table` to test mass assignment
+
+### Severity Assessment
+
+- **Critical**: Anon can read sensitive data (PII, financial) from tables with no RLS
+- **High**: Anon can write to tables (INSERT/UPDATE), enabling data manipulation
+- **High**: Filter abuse allows extraction of data that should be scoped per-user
+- **Medium**: Schema exposure reveals sensitive table/column structure
+- **Medium**: Count-based enumeration reveals record counts
+- **Low**: Non-sensitive public data accessible (may be intentional)
+"""

openhack/prompts/supabase/realtime.py

@@ -0,0 +1,93 @@
+"""
+Supabase Realtime security detection prompt.
+"""
+
+SUPABASE_REALTIME_PROMPT = """## Realtime Security in Supabase
+
+### Pre-Computed Recon Available
+
+The `supabase_recon` context already contains:
+- `supabase_recon.anon_access` -- tables accessible by anon (if anon can SELECT, realtime changes likely also leak)
+- `supabase_recon.rls_policies` -- RLS status per table (realtime respects RLS for postgres_changes)
+
+**Key insight: Realtime postgres_changes subscriptions are governed by the same RLS policies as direct table access. If a table has no RLS or permissive RLS, realtime will leak every change to any subscriber.**
+
+### What to Look For
+
+1. **Subscriptions to tables without RLS**
+   - `supabase.channel('*').on('postgres_changes', { table: 'orders' }, ...)` on a table without RLS
+   - Every INSERT/UPDATE/DELETE on that table is broadcast to all subscribers including anon
+   - Cross-reference: if `anon_access[table].select` is True, realtime changes are also exposed
+
+2. **Broadcast/presence channels without authentication**
+   - Broadcast and presence channels don't go through RLS
+   - Channel names derived from guessable IDs: `room:${userId}`, `org:${orgId}`
+   - Any client can join any channel name and receive/send messages
+
+3. **Sensitive data in realtime payloads**
+   - Even with RLS, the `NEW` and `OLD` records in change events include all columns
+   - If the table has sensitive columns (passwords, tokens, secrets), they leak via realtime
+   - Check if the subscription uses column filtering
+
+4. **Cross-room join/publish**
+   - Broadcast channels: client can publish to any channel they can join
+   - If channel names encode authorization (e.g., `admin-updates`), any client can subscribe
+
+### Vulnerable Patterns
+
+```typescript
+// VULNERABLE: Subscribing to table without RLS
+supabase
+  .channel('orders-changes')
+  .on('postgres_changes',
+    { event: '*', schema: 'public', table: 'orders' },
+    (payload) => {
+      console.log('Change received:', payload)
+      // Receives ALL changes to orders table from ALL users
+    }
+  )
+  .subscribe()
+```
+
+```typescript
+// VULNERABLE: Guessable channel name without auth verification
+supabase
+  .channel(`user:${otherUserId}`)  // Can join any user's channel
+  .on('broadcast', { event: 'notification' }, (payload) => {
+    // Receives another user's notifications
+  })
+  .subscribe()
+```
+
+### Safe Patterns
+
+```typescript
+// SAFE: Table has proper RLS, so only authorized changes are received
+// (Assuming orders table has: USING (auth.uid() = user_id) policy)
+supabase
+  .channel('my-orders')
+  .on('postgres_changes',
+    { event: '*', schema: 'public', table: 'orders',
+      filter: `user_id=eq.${user.id}` },
+    (payload) => {
+      // Only receives changes for current user's orders
+    }
+  )
+  .subscribe()
+```
+
+### Search Patterns
+
+1. Check `supabase_recon.rls_policies.tables_without_rls` -- any table subscribed to via realtime is vulnerable
+2. `grep` app code for `.channel(`, `.on('postgres_changes'`, `.on('broadcast'`, `.subscribe(`
+3. Check channel name patterns for guessable IDs
+4. Cross-reference subscribed tables with `supabase_recon.anon_access`
+5. Look for `filter:` parameter in postgres_changes subscriptions (reduces exposure but doesn't replace RLS)
+
+### Severity Assessment
+
+- **Critical**: Realtime subscription on sensitive table without RLS, leaking all changes to anon
+- **High**: Broadcast/presence channels with guessable names exposing user-specific data
+- **Medium**: Realtime subscription includes sensitive columns even with RLS
+- **Low**: Realtime on intentionally public data (e.g., public chat, live scores)
+"""

openhack/prompts/supabase/rls.py

@@ -0,0 +1,110 @@
+"""
+Supabase Row Level Security (RLS) misconfiguration detection prompt.
+"""
+
+SUPABASE_RLS_PROMPT = """## Row Level Security (RLS) Misconfigurations in Supabase
+
+### Pre-Computed Recon Available
+
+The `supabase_recon` context already contains the results of deterministic RLS analysis:
+- `supabase_recon.rls_policies.tables_without_rls` -- tables that have NO RLS enabled in migrations
+- `supabase_recon.rls_policies.tables` -- all tables with their RLS status and policy details
+- `supabase_recon.anon_access` -- runtime test results showing which tables the anon role can actually read/write
+
+**Start by cross-referencing these two datasets.** A table with no RLS in migrations AND `select: True` in `anon_access` is an instant critical finding.
+
+### What to Look For
+
+1. **Tables without RLS enabled**
+   - Every non-public table must have `ALTER TABLE ... ENABLE ROW LEVEL SECURITY`
+   - Absence means the table is wide open to any role with access
+
+2. **Overly permissive policies**
+   - `using (true)` or `with check (true)` grants unrestricted access
+   - Policies that don't reference `auth.uid()` or a tenant column
+
+3. **Per-operation gaps**
+   - SELECT policy exists but UPDATE/DELETE/INSERT policies are missing
+   - A table may be read-protected but write-open (or vice versa)
+
+4. **Policies trusting client-supplied data**
+   - Policy checks `user_id` column (which can be set by the client on INSERT) instead of `auth.uid()` from the JWT
+   - Example: `using (user_id = auth.uid())` on SELECT is fine, but `with check (user_id = auth.uid())` on INSERT trusts whatever the client sends as `user_id` if not also constrained
+
+5. **Missing tenant/org constraints**
+   - Multi-tenant apps must scope every policy to `org_id`/`tenant_id`
+   - Missing tenant constraint allows cross-tenant data access
+
+6. **Complex join inference**
+   - Even with RLS, count-based queries (`Prefer: count=exact`) can leak information about rows the user shouldn't see
+   - Policies applied after filters can allow inference via response timing or counts
+
+### Vulnerable Migration Patterns
+
+```sql
+-- VULNERABLE: Table created with NO RLS
+CREATE TABLE orders (
+  id uuid DEFAULT gen_random_uuid() PRIMARY KEY,
+  user_id uuid REFERENCES auth.users(id),
+  amount numeric,
+  status text
+);
+-- Missing: ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
+-- Missing: CREATE POLICY ... ON orders ...
+```
+
+```sql
+-- VULNERABLE: RLS enabled but permit-all policy
+ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "allow_all" ON documents FOR ALL USING (true);
+```
+
+```sql
+-- VULNERABLE: SELECT policy exists, but no INSERT/UPDATE/DELETE policies
+ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "users_read_own" ON profiles FOR SELECT USING (auth.uid() = id);
+-- No INSERT/UPDATE/DELETE policies = default deny, but could be intentionally missing
+-- or could be a gap if the app needs write access
+```
+
+```sql
+-- VULNERABLE: Policy trusts client-supplied user_id on INSERT
+CREATE POLICY "users_insert" ON posts FOR INSERT
+  WITH CHECK (user_id = auth.uid());
+-- If user_id is in the INSERT payload, client can set user_id = auth.uid() trivially
+-- But what about other columns like org_id, role, etc.?
+```
+
+### Safe Patterns
+
+```sql
+-- SAFE: Proper RLS with per-operation policies
+ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
+CREATE POLICY "users_read_own_orders" ON orders FOR SELECT
+  USING (auth.uid() = user_id);
+CREATE POLICY "users_insert_own_orders" ON orders FOR INSERT
+  WITH CHECK (auth.uid() = user_id);
+CREATE POLICY "users_update_own_orders" ON orders FOR UPDATE
+  USING (auth.uid() = user_id);
+CREATE POLICY "users_delete_own_orders" ON orders FOR DELETE
+  USING (auth.uid() = user_id);
+```
+
+### Search Patterns
+
+1. Check `supabase_recon.rls_policies.tables_without_rls` for immediate findings
+2. Cross-reference with `supabase_recon.anon_access` to confirm runtime exposure
+3. `grep` migration files for `using (true)` and `with check (true)`
+4. Check policies for `auth.uid()` references -- policies without it are suspicious
+5. Look for tables with SELECT policy but missing UPDATE/DELETE/INSERT policies
+6. For targeted probing: use `supabase_query_table` with filters like `or=(user_id.eq.X,user_id.is.null)` to test policy enforcement
+
+### Severity Assessment
+
+- **Critical**: Table without RLS + anon can read/write data at runtime (confirmed by `anon_access`)
+- **Critical**: Sensitive table (users, payments, PII) with `using (true)` policy
+- **High**: RLS enabled but policy is overly permissive or missing for some operations
+- **High**: Policy trusts client-supplied columns instead of JWT context
+- **Medium**: Missing tenant isolation in multi-tenant app
+- **Low**: RLS gap on non-sensitive, intentionally public data
+"""