NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY ships the key that bypasses every Row Level Security policy to every visitor, and "https://*.vercel.app/**" in your redirect list lets anyone with a Vercel account receive your users' magic-link and OAuth redirects. This skill finds those and the other Supabase mistakes below before you deploy, and tells you how to fix each one.

Your agent runs a scanner on supabase/config.toml (including [remotes] branch blocks), Edge Function code in supabase/functions, JavaScript and TypeScript client and server code (Next.js, SvelteKit, Nuxt, Vite, Astro, Expo), Expo app.json and eas.json, Python, Dart, Swift and Kotlin files that hold keys, and .env files. It reads the role inside legacy JWT keys, knows the new sb_publishable_ and sb_secret_ formats, ignores the fixed public keys of the local CLI stack, leaves app deep links (myapp://**) alone, treats env() and encrypted: values as references, and judges sign-up and password settings only when config.toml sets up a deployed project, so the file supabase init writes is not flagged. It never runs code or connects to Supabase. It returns BLOCK, REVIEW, or NOT FLAGGED, with the file, line, reason, and a safer approach. Secrets are never printed.

What it checks

BLOCK (fix before shipping)

• U01: the service_role or secret key in a public variable (NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_, PUBLIC_ and others, also in eas.json), a public variable holding a service key, or a service key under Nuxt runtimeConfig.public, Expo extra (app.config or app.json), Next.js env or Vite define
• U02: a service_role JWT or sb_secret_ key written in code, app.json, eas.json or a committed env template
• U03: OAuth, SMTP, SMS, CAPTCHA, auth hook, Studio, S3, Edge Runtime or Vault secrets written in config.toml instead of env()
• U04: redirect URLs whose wildcards accept other people's sites (** in the host, including the Netlify preview pattern from the docs, *.com, *.vercel.app, *-*.vercel.app, *.netlify.app, *.pages.dev and other shared hosts)

REVIEW (check before release)

• U11: Edge Functions with JWT verification off (verify_jwt = false, --no-verify-jwt, withSupabase auth 'none' or 'publishable') that use the service key and never check the caller (user JWT, secret key, webhook signature or secret header)
• U12: email sign-up without email confirmation on a deployed project
• U13: a minimum password length below 8 on a deployed project
• U14: anonymous sign-ins without CAPTCHA on a deployed project
• U15: JWT expiry above one hour, refresh token rotation off, single-address email change confirmation, or the nonce check skipped on a deployed project
• U16: site or redirect URLs with plain http:// for hosts that are not local
• U17: public storage buckets, in config.toml or created in code, unless the name's words mark public content such as avatars or profile-pictures
• U18: getSession() trusted in server code (middleware, proxy, route handlers, server components and actions) without getClaims() or getUser()

What's included

• The scanner (Python 3.9+, standard library only)
• A rules guide with the reason, safer approach and official Supabase source for each rule
• A risky and a safe example project (config.toml, an Edge Function, a Next.js middleware, a seed script and an env template), and the real report the scanner produces on the risky one

Limits

It reads files as written: settings changed only in the Supabase dashboard, Row Level Security policies and SQL migrations, and secrets set with supabase secrets set are not known. An Edge Function's caller check is looked for in the same file, and U11 needs the project folder that holds config.toml or the deploy script. Browser exposure is judged by variable prefixes and the Nuxt, Expo, Next.js env and Vite define settings, not by tracing imports. NOT FLAGGED is not a guarantee.

Contents

One ZIP file with 19 files: SKILL.md, the scanner in scripts/ (8 Python files), references/rules.md (every rule with its reason and safer approach), and examples/ (10 example files plus report.md, the real scanner output on the risky example).

How to use: This is an agent skill: a folder with a SKILL.md file and Python scripts that an AI coding agent such as Claude Code, Cursor, or Codex CLI can run. Unzip it into your agent's skills folder (for Claude Code: ~/.claude/skills/), then ask your agent to check your project. The scripts also run on their own with Python 3.9 or newer, with nothing to install. They read your files only: no network access, and nothing is sent anywhere.