security-review-estimator

name: security-review-estimator description: > Repo-aware security review for auth, data, env, upload, and server-boundary changes. Use when reviewing routes, server actions, Supabase access, proxy/session logic, video or Gemini flows, or any trust boundary in this repository.

Security Review Estimator

This skill is for security-sensitive review work in this repository.

It is not a generic checklist. It focuses on the actual trust boundaries and failure modes present in this codebase.

Use this skill for scoped repo-aware reviews. For repository-wide, deep, pull-request, commit, branch, or working-tree security scans, hand off to the codex-security plugin workflow when it is available.

When to use

• reviewing app/ routes or API handlers
• reviewing server actions
• changes in lib/auth/, lib/supabase/, or proxy.ts
• changes involving uploads, storage access, video inventory jobs, or Gemini pipelines
• env handling, secret access, or deploy-time validation
• any change that could widen access, leak data, or weaken server-side checks

When NOT to use

• performance-only reviews
• purely visual UI reviews with no auth or data implications
• general code quality review unless it directly affects a trust boundary

Review invariants

Check the repo against these non-negotiable expectations:

• auth enforcement must exist server-side, not only in UI state or route chrome
• privileged behavior and secrets must not leak to client code
• Supabase SSR and session boundaries must stay consistent
• data visibility must not widen accidentally across managers or users
• env-dependent behavior must not assume missing validation is safe
• sensitive flows must fail closed, not open

Workflow

1. Identify the entrypoint and trust boundary

Find:

• the request or invocation entrypoint
• where identity or session is established
• where validation happens
• where data or storage access occurs
• where the response or side effect leaves the server boundary

Typical high-risk files in this repo include:

• app/
• lib/auth/
• lib/supabase/
• proxy.ts
• lib/geminiTranscriptCleaner.ts
• services/video-inventory/

2. Trace auth and authorization on the server

Verify that server actions, routes, and storage operations enforce access on the server.

Look for these failure modes:

• UI-only gating with no server-side check
• trusting client-provided identifiers without ownership verification
• actions that can run with an authenticated session but without sufficient authorization
• route or proxy behavior that suggests protection exists when server code does not enforce it

3. Check secret and environment exposure

Review whether:

• service-role or privileged keys can leak into client bundles
• server-only boundaries are preserved where expected
• secret-bearing env vars are accessed only on the server
• errors, logs, or debug output expose secrets or internal details
• missing env validation could silently degrade into unsafe behavior

4. Check data scope, storage access, and RLS assumptions

Review whether queries, storage paths, and job records preserve user or manager scoping.

Look for:

• cross-user reads or writes
• widened filters
• missing ownership checks
• assumptions that RLS exists without verifying the actual access path
• server-side privileged access that bypasses protections without compensating checks

5. Check upload, video, and Gemini surfaces

For upload and AI pipeline changes, review:

• file ownership and authorization
• signed URL or storage token exposure
• unsafe MIME, size, or path assumptions
• background jobs that can be triggered or observed by the wrong user
• error messages that leak internals, model details, or secret-bearing context

6. Report findings first

The final review should prioritize:

1. concrete security findings ordered by severity
2. file and line references when available
3. missing tests or missing server-side checks
4. residual risk only after the findings

If no findings are present, say so explicitly and call out any remaining test gaps or assumptions.

Output contract

Use a findings-first review format:

1. Findings
2. Open questions or assumptions
3. Brief change summary only if useful

Non-goals

• style review
• performance tuning
• broad architecture critique unrelated to security or trust boundaries