A. Security & Data Safety · Prompt 8

Personal Data Flow & Storage Audit

Get the free PDF

Why it matters

A console.log of a user object can land in a host's logs, where anyone with dashboard access can read it.

Modeled on

Data-flow reviews that trace personal data from collection to storage to third parties.

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.

Personal Data Flow & Storage Audit: what to check
Map how personal data moves through this app. Do not print real user values you find in fixtures. Describe the field and the path.
1. List where the app collects data: signup, profile, payment forms, device or location fields, and uploads.
2. For each field, trace the next hop you can see in code: which table, which third-party request, which log line.
3. Search console.log, logger calls, and error handlers for emails, phone numbers, tokens, passwords, or a whole user object. Quote the file and line, not the value.
4. List third-party SDKs (analytics, crash reports, email, AI) and which user fields are passed in. Flag a payload that sends more than that call needs.
5. Confirm passwords are hashed with bcrypt, argon2, or scrypt before storage, and are not returned by an API or written to a log. If you only see a comment that says "hashed" and not the call, mark it Needs manual check.
6. Check cookies for HttpOnly, Secure, and SameSite. Flag personal data written to localStorage, which any script on the page can read.
7. Check API responses for over-fetching: a handler that returns columns the screen does not use, especially email, phone, or tokens.
8. Say whether the code has a path for a user to request account or data deletion. If it does not, list it as a gap even if you are not giving legal advice.
9. Finish with a short map: collected, stored, sent externally, and what a later fix pass should change. Do not change it now.

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 P08, for example P08-1, P08-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. Personal Data Flow & Storage Audit: what to check Map how personal data moves through this app. Do not print real user values you find in fixtures. Describe the field and the path. 1. List where the app collects data: signup, profile, payment forms, device or location fields, and uploads. 2. For each field, trace the next hop you can see in code: which table, which third-party request, which log line. 3. Search console.log, logger calls, and error handlers for emails, phone numbers, tokens, passwords, or a whole user object. Quote the file and line, not the value. 4. List third-party SDKs (analytics, crash reports, email, AI) and which user fields are passed in. Flag a payload that sends more than that call needs. 5. Confirm passwords are hashed with bcrypt, argon2, or scrypt before storage, and are not returned by an API or written to a log. If you only see a comment that says "hashed" and not the call, mark it Needs manual check. 6. Check cookies for HttpOnly, Secure, and SameSite. Flag personal data written to localStorage, which any script on the page can read. 7. Check API responses for over-fetching: a handler that returns columns the screen does not use, especially email, phone, or tokens. 8. Say whether the code has a path for a user to request account or data deletion. If it does not, list it as a gap even if you are not giving legal advice. 9. Finish with a short map: collected, stored, sent externally, and what a later fix pass should change. Do not change it now. 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 P08, for example P08-1, P08-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.