A. Security & Data Safety · Prompt 3

Database Rules & Row-Level Access

Why it matters

If the database is called from the browser, the rules are the security of the app. A default or test-mode rule can leave every row readable.

Modeled on

Supabase Row Level Security and Firebase Security Rules.

How to run this prompt

Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.
Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.
Read the report. Keep the IDs you agree with.
Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.
Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.

Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.
Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.
Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.

The audit prompt

MODE: AUDIT ONLY. Do not create, edit, or delete any file. Do not run commands
that change anything: no installs, migrations, git commits, deploys, or "--fix" flags.
If your tool has an Ask, Plan, Chat, or Discuss mode, use it for this prompt.

Before you start:
- Tell me the stack you detect (framework, language, database, auth, hosting,
  payment provider) and which folders you will review.
- If a check below does not apply to this stack, write "Not applicable" and why.
- If you can run read-only commands, run the ones listed. If you cannot, list them
  so I can run them and paste the output.

Database Rules & Row-Level Access: what to check
Audit database access as if anyone can copy the public client keys and call the database directly. Rules in the repo can differ from rules deployed in the dashboard. Mark dashboard-only state as Needs manual check.
1. List every table or collection. For each, say who can read, insert, update, and delete, and whether that is enforced by database rules (RLS, Firestore or Storage rules, role grants) or only by application code.
2. Flag RLS that is off, a policy of USING (true) or WITH CHECK (true), and Firestore rules of the form allow read, write: if true. Also flag leftover test-mode rules.
3. For user-owned rows, confirm the rule compares the row's user id to the authenticated user id on insert, update, and delete, not only on read.
4. Confirm a client write cannot set role, is_admin, credits, price, or owner id. Those columns should be omitted from the policy's allowed columns, or set only by a trigger or the server.
5. Confirm the Supabase service_role key, a Firebase Admin SDK credential, or any connection that bypasses RLS is used only on the server. Searching the client bundle and NEXT_PUBLIC_ or VITE_ names is enough for the repo. A deployed dashboard setting is Needs manual check.
6. For storage buckets, say which are public, which are private, and whether a user can list or read another user's file by guessing the path.
7. Describe a read-only test you want me to run with a normal user's token against another user's id. Do not run a write against a shared or production database.
8. If SQL policies live in migrations, cite the migration file. If they are only in the hosted console, say the repo cannot prove what is deployed.

Evidence rules:
- Every finding cites a file path and line number, or the exact command output used.
- Mark each finding Confirmed (seen in the code) or Needs manual check (depends on
  something outside the repo, such as a dashboard setting or production data).
- Never print a full secret. Show the first 4 characters and the location only.
- If you are not sure, say so. Do not invent files, settings, or results.

Severity: Critical = exploitable now, or leaks real data or money. High = serious
with little effort. Medium = weakens defenses or needs a second bug. Low = hygiene.

Report:
- Summary: count of findings by severity.
- Table: ID | Severity | Confirmed? | Finding | Evidence | Why it matters | Suggested fix | Effort
  (IDs for this prompt use the prefix P03, for example P03-1, P03-2.)
- Checked and fine: what you verified is already OK.
- Could not check: what I need to look at myself, and where.

Then stop. Do not fix anything. Ask me which IDs I want fixed.

Get the free PDF

Related prompts

Share this prompt

WhatsApp LinkedIn X

How to run this prompt

Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.

Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.

Read the report. Keep the IDs you agree with.

Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.

Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.

Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.

Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.

Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.

The audit prompt

MODE: AUDIT ONLY. Do not create, edit, or delete any file. Do not run commands that change anything: no installs, migrations, git commits, deploys, or "--fix" flags. If your tool has an Ask, Plan, Chat, or Discuss mode, use it for this prompt. Before you start: - Tell me the stack you detect (framework, language, database, auth, hosting, payment provider) and which folders you will review. - If a check below does not apply to this stack, write "Not applicable" and why. - If you can run read-only commands, run the ones listed. If you cannot, list them so I can run them and paste the output. Database Rules & Row-Level Access: what to check Audit database access as if anyone can copy the public client keys and call the database directly. Rules in the repo can differ from rules deployed in the dashboard. Mark dashboard-only state as Needs manual check. 1. List every table or collection. For each, say who can read, insert, update, and delete, and whether that is enforced by database rules (RLS, Firestore or Storage rules, role grants) or only by application code. 2. Flag RLS that is off, a policy of USING (true) or WITH CHECK (true), and Firestore rules of the form allow read, write: if true. Also flag leftover test-mode rules. 3. For user-owned rows, confirm the rule compares the row's user id to the authenticated user id on insert, update, and delete, not only on read. 4. Confirm a client write cannot set role, is_admin, credits, price, or owner id. Those columns should be omitted from the policy's allowed columns, or set only by a trigger or the server. 5. Confirm the Supabase service_role key, a Firebase Admin SDK credential, or any connection that bypasses RLS is used only on the server. Searching the client bundle and NEXT_PUBLIC_ or VITE_ names is enough for the repo. A deployed dashboard setting is Needs manual check. 6. For storage buckets, say which are public, which are private, and whether a user can list or read another user's file by guessing the path. 7. Describe a read-only test you want me to run with a normal user's token against another user's id. Do not run a write against a shared or production database. 8. If SQL policies live in migrations, cite the migration file. If they are only in the hosted console, say the repo cannot prove what is deployed. Evidence rules: - Every finding cites a file path and line number, or the exact command output used. - Mark each finding Confirmed (seen in the code) or Needs manual check (depends on something outside the repo, such as a dashboard setting or production data). - Never print a full secret. Show the first 4 characters and the location only. - If you are not sure, say so. Do not invent files, settings, or results. Severity: Critical = exploitable now, or leaks real data or money. High = serious with little effort. Medium = weakens defenses or needs a second bug. Low = hygiene. Report: - Summary: count of findings by severity. - Table: ID | Severity | Confirmed? | Finding | Evidence | Why it matters | Suggested fix | Effort (IDs for this prompt use the prefix P03, for example P03-1, P03-2.) - Checked and fine: what you verified is already OK. - Could not check: what I need to look at myself, and where. Then stop. Do not fix anything. Ask me which IDs I want fixed.