We Scanned Supabase and It Scored 100/100 — Here's What Perfect Security Looks Like

Most applications validate at one layer and trust the rest. Supabase validates twice — TypeScript catches type mismatches at compile time, Zod catches them at runtime. This matters because TypeScript types disappear at runtime. A POST body typed as `{ email: string }` in TypeScript is still `unknown` when it arrives from the network. Zod's `schema.parse()` turns that unknown into a verified shape before it touches any business logic. Combined, these two layers mean no raw request data ever reaches a database query or a downstream function without being explicitly validated.

// Pattern Supabase uses throughout its API routes
import { z } from 'zod'

const CreateProjectSchema = z.object({
  name:         z.string().min(1).max(64),
  region:       z.enum(['us-east-1', 'eu-west-1', 'ap-southeast-1']),
  plan:         z.enum(['free', 'pro', 'enterprise']),
  organization_id: z.string().uuid(),
})

// At the API boundary — before ANY business logic
const result = CreateProjectSchema.safeParse(req.body)
if (!result.success) {
  return res.status(400).json({ error: result.error.flatten() })
}
// result.data is now fully typed AND runtime-verified
const { name, region, plan, organization_id } = result.data

The most common authorization mistake is doing it only in application code. If an attacker bypasses the app layer — via a misconfigured proxy, a forgotten debug route, a SSRF flaw — they hit the database directly. Row Level Security (RLS) in PostgreSQL means the database itself enforces access control. Every query runs as the authenticated user, not as a superuser. A query that should return rows for user A will return zero rows if run as user B, even if issued directly against the database without going through the application. This is defense-in-depth: access control that cannot be bypassed by finding a hole elsewhere in the stack.

-- RLS policy pattern from Supabase's own infrastructure
-- Users can only read/modify their own project data
CREATE POLICY "Users can only access their own projects"
  ON projects
  FOR ALL
  USING (auth.uid() = owner_id);

-- Service-level operations use a separate, tightly-scoped role
CREATE POLICY "Service role can manage all projects"
  ON projects
  FOR ALL
  TO service_role
  USING (true);

-- RLS is enforced at the Postgres level — not bypassable
-- from application code or direct DB connections

Custodia scanned 628 files — including configuration files, test helpers, and example code — and found zero hardcoded secrets. This sounds like a low bar, but it is surprisingly rare in large codebases. The pattern that trips teams up is "temporary" secrets in test files, example configurations with real-looking placeholder values, or fallback values in code for when the env var is missing. Supabase's codebase has none of these. Every secret reference consistently reads from `process.env`, with no in-code fallback defaults that could ship to production accidentally.

// What Supabase's pattern looks like — clean env var access
// No fallback values, no hardcoded strings
const supabaseUrl     = process.env.SUPABASE_URL!
const supabaseAnonKey = process.env.SUPABASE_ANON_KEY!
const jwtSecret       = process.env.JWT_SECRET!

// ❌ The pattern that fails scans in most codebases:
// const jwtSecret = process.env.JWT_SECRET || 'dev-fallback-secret'
//                                              ^^^^^^^^^^^^^^^^^^^^
//                   This fallback ships to production when env var is missing

// ✓ Instead, fail loudly if config is missing:
if (!supabaseUrl || !jwtSecret) {
  throw new Error('Missing required environment variables')
}

Logging is a double-edged sword. Insufficient logging means you cannot detect or investigate incidents. Excessive logging means you are writing user data, tokens, and PII to log files that eventually end up in a SIEM, a third-party logging service, or a developer's screen. Supabase threads this needle by logging structured events through Sentry — enough information to reconstruct what happened, but with sensitive fields explicitly omitted. No JWT payloads, no raw request bodies, no API key values in log lines.

// Supabase-style structured logging — events, not raw data
import * as Sentry from '@sentry/node'

// ✓ Log the event with safe metadata
Sentry.captureEvent({
  message:   'auth.sign_in',
  level:     'info',
  extra: {
    user_id:  userId,      // ✓ safe — internal ID
    provider: 'email',     // ✓ safe — enum value
    // ❌ Never log:
    // password, token, session, request.body
  },
})

// ✓ Log errors with context, not raw caught values
try {
  await processRequest(data)
} catch (err) {
  Sentry.captureException(err, {
    extra: { operation: 'processRequest', userId },
    // ❌ Not: { rawInput: data } — could contain PII
  })
  throw err
}

Supabase uses the OpenAI SDK for AI-powered features. The Custodia scan specifically checks for AI security controls (LLM-01 through LLM-15) — prompt injection vectors, insecure output handling, missing token limits, and lack of input sanitization before LLM calls. Supabase scored 100 across all AI checks. The SDK is called through a centralized wrapper rather than being called directly from routes, allowing consistent governance: token limits enforced, user inputs sanitized before being incorporated into prompts, and model outputs validated before being returned to clients.

// AI governance pattern — centralized LLM wrapper
// Never call OpenAI directly from route handlers
async function callAI(
  systemPrompt: string,
  userInput: string,
  opts: { maxTokens?: number } = {}
): Promise<string> {
  // ✓ Sanitize user input before incorporating into prompt
  const sanitized = userInput
    .replace(/<[^>]*>/g, '')       // strip HTML
    .slice(0, 2000)                // enforce input length limit
    // Add prompt injection defenses specific to your use case

  const response = await openai.chat.completions.create({
    model:      'gpt-4o',
    max_tokens: opts.maxTokens ?? 1024,  // ✓ always set token limit
    messages: [
      { role: 'system',  content: systemPrompt },
      { role: 'user',    content: sanitized },
    ],
  })

  const output = response.choices[0]?.message?.content ?? ''

  // ✓ Validate output before returning to client
  return OutputSchema.parse(output)
}

npx @custodia/cli scan --repo your-org/your-repo