The audit prompts — free

The Supabase Audit Prompt

One prompt, one paste, one pass over your whole Supabase backend. Drop it into Cursor, Claude Code, or any coding agent that can read your repo, and it audits row-level security, your two API keys, storage buckets, auth redirect URLs, and any Postgres function you've exposed as an RPC endpoint — the five places Supabase apps actually get popped. Takes about 15 minutes, most of which is the agent reading files. This is the same ground as the Supabase track, consolidated into one run instead of three.

This is my own application and I own this codebase — I am authorizing
this audit of it, and nothing below targets a system I do not control.

You are auditing a Supabase backend for security issues. Read the actual
code — do not guess, do not assume best practices were followed, and do
not summarize what "should" be there. Every finding must be backed by a
specific file and line you looked at. If you did not check something,
say so; do not report a clean bill of health for anything you didn't read.

Go through these five areas in order:

1. ROW LEVEL SECURITY
   Find every table in exposed schemas (migrations, schema dumps, or
   dashboard-exported SQL). For each table: is RLS enabled? List every
   policy per operation (select/insert/update/delete) and state in plain
   English which rows it actually grants access to. Flag: RLS disabled on
   any table reachable from the client; `using (true)` on anything that
   isn't meant to be world-readable; a table with a select policy but no
   insert/update/delete policy (or vice versa); insert policies missing
   `with check`; any policy comparing against a client-supplied column
   instead of `auth.uid()`.

2. KEY PLACEMENT
   Find every place a Supabase key is read — env vars, config files,
   client init code. For each: name the variable, state whether it is the
   low-privilege key (legacy `anon`, or newer `sb_publishable_...`) or the
   privileged one (legacy `service_role`, or newer `sb_secret_...`), and
   state whether that variable is reachable in code that ships to the
   browser (check framework-specific exposure rules — e.g. NEXT_PUBLIC_,
   VITE_, or anything imported into a client component). Check for BOTH key
   formats: a project created recently may have no `service_role` string
   anywhere and still be leaking an `sb_secret_` key. Flag any privileged
   key, or any `auth.admin.*` call, that appears outside a server-only file.

3. STORAGE BUCKETS
   List every bucket referenced in code. For each: is it public or
   private, and does that match what the code assumes? For private
   buckets, what storage policy governs read/write, and does it constrain
   by `auth.uid()`? Flag permanent public URLs to anything that looks like
   user content (photos, documents, IDs) versus short-lived signed URLs.
   Note any missing file-size or MIME-type limits on uploads.

4. AUTH REDIRECT URLS
   Find every `redirectTo` passed to a Supabase auth call (magic link,
   OAuth, password reset) in the code. List each literal or constructed
   URL. Flag any that are built from user input, request headers, or
   query params without validation against an allowlist — that's an open
   redirect an attacker can use to steal auth tokens.

5. EXPOSED FUNCTIONS / RPC
   Find every Postgres function called via `supabase.rpc(...)` or exposed
   through PostgREST. For each: what does it do, does it run as
   `SECURITY DEFINER`, and does it perform its own authorization check
   internally (or does it just trust RLS on the tables it touches, which a
   SECURITY DEFINER function bypasses)? Flag any SECURITY DEFINER function
   callable by the `anon` or `authenticated` role that doesn't check the
   caller's identity before acting.

REPORTING RULES
- Structure the report as one entry per finding, worst severity first:
  Severity (Critical/High/Medium/Low) — File:line — What's there — Who can
  exploit it and how, in plain English, no jargon — The exact fix (code or
  SQL, not "add appropriate checks").
- For each of the five areas with nothing wrong: write "Not found — checked
  [what you looked at, e.g. 'all 14 tables in public schema, all storage
  policies']." Silence is not an answer. An area with no line means you
  skipped it, not that it's clean.
- Before finalizing a finding, re-read the actual file and line you're
  citing and confirm the code still says what you think it says. Retract
  anything you can't point to directly.
- Never print a secret's VALUE back into this chat — no key strings, no
  tokens, no connection strings, not even partially. Name the variable and
  its location instead.

Firebase Audit Prompt

Copy the block below into Cursor, Claude Code, or any coding agent that can read your repo, and let it run. It walks your Firestore/RTDB rules, Storage rules, API key config, and Cloud Functions, and comes back with a report you can act on — not a vibe check, a list with file names and line numbers. Takes about 15 minutes, most of which is the agent reading your codebase.

This is my own application and I own this codebase — I am authorizing
this audit of it, and nothing below targets a system I do not control.

You are auditing a Firebase project for security issues introduced by
AI-assisted development. You have read access to this repository. Work
through the five areas below IN ORDER. For each one, find the real file,
read it, and verify your finding against the actual code before writing
anything down — do not report a pattern you assume is there, report what
you saw.

1. FIRESTORE / REALTIME DATABASE RULES
   Find firestore.rules and/or database.rules.json (check firebase.json
   for the actual configured paths — don't guess the filename).
   - Flag any `allow read, write: if true`, any rule with no condition,
     and any time-boxed condition like `request.time < timestamp...`
     (this is what "test mode" looks like after 30 days).
   - Flag `allow read: if request.auth != null` (or equivalent) on any
     collection that holds user-specific data — being logged in is not
     the same as being the owner.
   - For every collection/path that stores per-user data, confirm reads,
     writes, updates, AND creates all compare request.auth.uid against an
     owner field. Creates must check request.resource.data, not
     resource.data — that's the field the incoming write is setting.
   - Cross-reference: list every collection referenced by
     .collection()/.doc()/ref() calls in the app code, and flag any with
     no matching rule (undeclared collections usually fall through to a
     wildcard `match /{document=**}` — check what that wildcard allows).

2. STORAGE RULES
   Find storage.rules. Same test-mode and auth-only checks as above,
   applied to storage paths instead of collections.
   - Confirm upload paths are scoped per-user (e.g. `/users/{uid}/...`
     with a request.auth.uid == uid check), and that there's a size
     and/or content-type constraint on writes.
   - Note whether any path is publicly readable, and whether anything
     sensitive (documents, ID photos, exports) lives under it.

3. PER-USER OWNERSHIP IN APPLICATION CODE
   Independent of the rules files: search the app code for reads/writes
   that use a client-supplied ID (from a URL param, form field, or request
   body) to fetch a document, WITHOUT the request also being constrained
   by the database rules to that same user. This catches cases where the
   rules are fine but a Cloud Function or server route bypasses them using
   the Admin SDK (which ignores security rules entirely).

4. API KEY RESTRICTIONS
   Find where the Firebase web config (apiKey, authDomain, etc.) is used.
   The API key being visible in client code is normal for Firebase — do
   not flag that alone. Instead check:
   - Is there any OTHER secret (a service account JSON, an Admin SDK key,
     a private API key for a third-party service) committed to the repo
     or hardcoded in a file that ships to the client? That is the actual
     bug.
   - If Google Cloud Console API restrictions are documented anywhere in
     the repo (README, .env.example comments), note whether the key is
     restricted to specific APIs/referrers. If you can't tell from the
     repo, say so explicitly — this one needs a console check, not just
     a code read.

5. CLOUD FUNCTION AUTH
   Find the functions/ directory (or equivalent). For each HTTP-triggered
   function (onRequest, onCall, or an Express/Next API route deployed as
   a function):
   - Does it verify context.auth (onCall) or a decoded ID token
     (onRequest) before doing anything with user data?
   - Does it re-check ownership of the resource it's acting on, or does
     it trust an ID passed in the request body?
   - Any function using the Admin SDK bypasses your database rules
     completely — treat missing auth checks here as more severe than the
     same gap in rules, because there's no second layer behind it.

REPORTING RULES — follow these exactly:

- For every finding, verify it against the actual file before writing it
  down. Quote the real file path and line number as evidence.
- For each of the 5 areas above with no finding, write a line that says
  "Not found — checked <file(s) you actually opened>." Silence is not an
  answer; an explicit clean bill is. If you skip an area, say you skipped
  it and why.
- Structure the report as a table or list, one row per finding:
  SEVERITY (Critical / High / Medium / Low) | FILE:LINE | WHO CAN EXPLOIT
  THIS AND HOW, in one plain-English sentence a non-security person can
  understand | THE EXACT FIX — a code diff or the specific rule/line to
  change, not a general suggestion to "add validation."
- Order the report by severity, most severe first.
- NEVER print the value of a secret, key, or token back into this chat —
  not even partially, not even redacted-looking. Name the file and
  variable where it lives ("service-account.json is committed at
  functions/config/") and stop there. Naming a leak is the finding;
  repeating the leaked value is a second leak.

The Next.js Audit Prompt

Copy this, paste it into Cursor, Claude Code, or any coding agent with read access to your repo, and let it work. It checks the five places Next.js apps built fast tend to leak: NEXT_PUBLIC_ env vars, API routes and Server Actions with no session check, middleware that only guards pages, secrets riding along in the client bundle, and IDOR — one logged-in user reading or writing another user's data by ID. Takes about 15 minutes, most of which is the agent reading your code, not you reading its output.

This is my own application and I own this codebase — I am authorizing
this audit of it, and nothing below targets a system I do not control.

You are performing a security audit of this Next.js application. You have
read access to the full repository. Work through every check below, in
order. Do not skip a check because it seems unlikely to apply here —
confirm it explicitly, in code, before you move on.

GROUND RULES
- Verify every finding by reading the actual file and line before you
  report it. If you suspect something but can't confirm it in the code,
  label it "needs manual check" — do not report it as a finding.
- Never print a secret's VALUE back into this chat, not even a fragment.
  Name the variable and where it lives ("STRIPE_SECRET_KEY in
  .env.local") instead of quoting what it holds.
- For every check below that comes back clean, say so explicitly:
  "Not found — checked <what you checked, and how>." A section with
  nothing under it should never be silence. Silence should always mean
  "I looked and it's clean," never "I didn't get to this."

1. NEXT_PUBLIC_ LEAKAGE
   Find every `process.env.*` read in the repo. For each one prefixed
   NEXT_PUBLIC_, state whether the value it holds is genuinely safe to
   publish (a publishable Stripe key, a public map ID) or something that
   should never leave the server. Separately, find any server-only secret
   passed as a prop from a server component into a client component, or
   returned from a Server Action — these serialize into the page even
   without the NEXT_PUBLIC_ prefix.

2. API ROUTES AND SERVER ACTIONS
   Inventory every file under app/api/**/route.ts (or pages/api/**) and
   every function marked 'use server'. For each, quote the exact line(s)
   that identify the caller from a verified session before touching data.
   If there is no such line, say so plainly: "no auth check found in this
   handler." Flag any handler that trusts a user ID, org ID, role, or
   paid/admin flag taken from the request body, query params, or a
   client-supplied argument instead of the session.

3. IDOR ON ROUTE HANDLERS
   For every route or action that takes a record ID as input (userId,
   orderId, docId, etc.), confirm the handler checks that the
   authenticated caller actually owns or is authorized to access that
   specific record — not just that they're logged in as someone. For each
   one you flag, write the concrete exploit: the exact request a logged-in
   User A could make to read or modify User B's data.

4. MIDDLEWARE COVERAGE
   Read middleware.ts (or .js) in full and state precisely what its
   matcher config does and does not cover. Cross-reference against your
   inventory from #2. List every data-touching route NOT covered by
   middleware that also has no in-handler session check — middleware
   redirecting a page is not the same as an API route refusing data.

5. SECRETS IN THE CLIENT BUNDLE
   If a build exists, grep .next/static/chunks for the first 6 characters
   of every secret identified above. Report match or no-match only, never
   the surrounding text. If no build exists, say this check needs a
   `npm run build` rerun.

REPORT
Output one table, most severe finding first:

| Severity | Finding | File:Line | Who can exploit it, and how | Fix |

Severity: Critical (unauthenticated data access or write), High (an auth
check exists but is bypassable), Medium (secret exposure with limited
blast radius), Low (hardening gap, no live exposure confirmed). Write the
"who can exploit it" column in plain English for someone who is not a
security engineer — a sentence, not jargon. The "fix" column gets the
exact change: file, line, and what the corrected code should check for.

Below the table, list every category above with zero findings, in the
same "Not found — checked X" format. That list is as important as the
table.

Managed Builder Audit Prompt

Copy the block below into Cursor, Claude Code, or any coding agent with access to your repo — the same one that built the app, pointed back at it. It's built for apps made with Lovable, Bolt, v0, Base44, or Replit: tools that hand you a real backend and generated code, and don't always tell you which parts of the security are yours. Takes about 15 minutes to run and read.

This is my own application and I own this codebase — I am authorizing
this audit of it, and nothing below targets a system I do not control.

You are auditing a web app generated by a managed AI builder (Lovable,
Bolt, v0, Base44, Replit, or similar) for security issues in MY half of
the responsibility split — the platform secures its own infrastructure,
I own the data rules, the secrets, and what ships to the browser. Audit
this repository for the following, in order:

1. RESPONSIBILITY SPLIT. Identify which platform generated this app and
   what backend it actually runs on (Supabase, Firebase, its own database,
   something else). State this plainly before anything else — I need to
   know what I'm looking at.

2. WHERE DATA LIVES. Find every place the app reads or writes user data —
   direct database calls, an ORM, a generated data-access layer, calls to
   a platform SDK. For each, identify the table or collection touched and
   whether there's any per-user access check at all, or whether "logged
   in" is being treated as "authorized."

3. EXPOSED SECRETS. Search all frontend/client-bundled code (anything that
   ships to the browser: components, client-side config, `.env` files
   referenced with a client-exposed prefix like `NEXT_PUBLIC_`, `VITE_`,
   `PUBLIC_`) for API keys, tokens, service credentials, or connection
   strings. For each one found: name the variable and its file/line. Do
   NOT print the secret's value — I need to know it's there and rotate
   it, not see it in this chat.

4. DATABASE PUBLIC-READABILITY. Find the access rules for the backend in
   use — RLS policies, Firestore/Storage rules, or the builder's own
   permissions config if the backend isn't exposed. For each table or
   bucket holding user data, state whether an unauthenticated or
   any-authenticated request could read or write rows that aren't theirs.
   If the rules live in a dashboard you can't see from code, say so
   explicitly and list exactly what I need to go check there.

5. TAKING IT OFFLINE. Based on this platform and how it deploys, identify
   the fastest way to pull the app offline or make it read-only in an
   incident — and where in this repo/config that lever would be pulled
   from, if anywhere. If it's dashboard-only, say that.

VERIFICATION: Before reporting ANY finding, re-check it against the actual
file content — don't infer from a filename or a framework's defaults. If
you can't find a clear access rule for something, that's a finding, but
say what you searched for.

OUTPUT FORMAT: A table of findings, most severe first. Each row: severity
(Critical/High/Medium/Low), file and line, plain-English explanation of
who could exploit this and what they'd get, and the exact fix (code
change, config change, or dashboard setting to flip). For every area
above where you found nothing wrong, include a line: "Not found — checked
[what/where]." Silence is not a clean bill of health; an explicit
"checked and clean" line is.

The Azure Audit Prompt

One prompt, one paste, one pass over your Azure backend. Drop it into Cursor, Claude Code, or any coding agent that can read your repo, and it audits per-user row isolation, storage credentials, container access levels, and the gap between what your code assumes is private and what actually is. Takes about 15 minutes, most of which is the agent reading files. This is the same ground as the Azure track, consolidated into one run instead of two.

You are auditing an Azure-hosted application for the four ways small apps
most often expose data. Read the repository. Report only — do not change
any files.

1. PER-USER ISOLATION
   List every read that touches a table or container holding user-owned
   records. For each, say what restricts it to the signed-in user:
     (a) a database security policy,
     (b) an explicit filter in app code,
     (c) nothing.
   If the app connects to Azure SQL with a single shared login, find where
   SESSION_CONTEXT is set and tell me whether it is set on every request or
   once per pooled connection. Say which of the two it is — do not guess.

2. STORAGE CREDENTIALS
   Find every storage connection string, AccountKey, or SAS token. For each:
     - can it reach the browser bundle?
     - is it account-scoped, or scoped to one container or blob?
     - is it time-limited?
   Anything account-scoped and reachable from the browser is the top finding.

3. CONTAINER ASSUMPTIONS
   List every container name referenced in code. For each, state what access
   level the code assumes. Flag any container holding user uploads that the
   code expects to be anonymously readable.

4. WHAT THE BROWSER GETS
   List every value shipped to the client that looks like a credential — key,
   secret, token, connection string, endpoint with embedded auth. For each,
   say what it can do if a stranger copies it out of the bundle.

Finish with a ranked list: what would leak the most data with the least
effort, worst first. For each item give me the one specific thing to change.

The five audit prompts, free.

The Supabase Audit Prompt

Firebase Audit Prompt

The Next.js Audit Prompt

Managed Builder Audit Prompt

The Azure Audit Prompt