privacy-review

name

privacy-review

description

A fearless privacy & security inventory of ANY app that holds sensitive user data — hunts the gap between what privacy/security the code CLAIMS and what it actually ENFORCES. DB/ecosystem-agnostic. Reports 🔴/🟠/🟡/🟢 per check; optional --gold emits verified findings as portable training pairs. Use before a public release, before shipping a sensitive feature (matching/sharing/DMs/AI-over-user-data), or after adding auth/payments/PII/AI.

/privacy-review — fearless code moral inventory

The most dangerous pattern in apps holding sensitive data is stated intent the code doesn't enforce: "stored encrypted" over a plaintext column; "we can't read your data" over a server-held key; "only X users can do Y" enforced in a spec but not the query. This skill hunts that gap. No ecosystem dependencies — works on any stack, detects DB/auth from the repo.

Usage

/privacy-review                 # whole app, sensitive surfaces first
/privacy-review <path|feature>  # scope to a feature/dir
/privacy-review --live          # also verify against the deployed DB/grants, not just source
/privacy-review --gold          # append verified findings to .audit/gold-pairs.jsonl (see README)

Work sensitive-first: enumerate the highest-harm content (health/recovery/sexual, private messages, financial, precise location) and review the surfaces that touch it before anything else.

Severity

Icon	Level	Meaning
🔴	critical	Live or trivially-reachable exposure of sensitive content / identity / money. Fix before release.
🟠	high	Real exposure behind a non-trivial condition, or a safety control that's unenforced.
🟡	medium	Weakness, hygiene gap, or a claim that's technically true but easy to misread.
🟢	clear	Verified correct — record it so the next reviewer doesn't re-derive it.

---

Check 1 — stated-vs-actual gap (the heart of it; run first, run hard)

For every place code/comments/docs/marketing claim a privacy property, find the enforcement.

grep -rinE "encrypt|private|secure|anonym|pseudonym|only you|cannot read|zero.?knowledge|not stored|deleted|hashed|HIPAA|GDPR|consent" . | grep -v node_modules

For each claim ask where is this enforced, and what happens if I don't cooperate?

• "Stored encrypted" → a real crypto primitive, or a cleartext column with an aspirational comment?
• "Pseudonymous / we don't know who you are" → keyed to a pseudonym, or one join from the email?
• "We can't read it" → does the server hold the key? Then the honest claim is "encrypted, we hold the keys," not zero-knowledge.
• "X only for Y users" → enforced in the handler/query, or only described?

🔴/🟠: a claimed protection with no enforcement, or one enforced in a single path but bypassable via another (a second endpoint, an admin route, a job, a direct API/RPC call). Severity = sensitivity of what it "protects."

Check 2 — identity-source triage (privileged / elevated code)

For anything that runs with elevated rights (Postgres SECURITY DEFINER, admin handlers, anything bypassing row-level checks), the question isn't "does it have a grant" — it's whose identity does it act on, and can an arbitrary caller reach a privileged action.

Bucket	Signature	Severity
1 · Param-identity	takes a target user_id/id as a parameter, acts on it with no caller == target check	🔴 cross-user read/write
2 · Unguarded privileged write	mutates balances/roles/subscriptions with no caller-auth check, reachable by ordinary users	🔴 forgery / escalation
3 · Self-scoped	identity derived internally from the session; all access scoped to it	🟢 safe (revoking anon is hygiene, not a fix)
4 · Trigger/event fns	fired by events, not callable as an endpoint	⚪ N/A here (still check search_path/injection)

Triage rule: a missing access-revoke is hygiene; the critical finding is Bucket 1 or 2 only — don't drown the report by escalating 3/4. Review the latest/deployed definition of a redefined function.

Check 3 — sensitive-content classification & encryption posture

Classify every store of user content by harm-if-leaked, then state the honest posture:

Posture	Who can read	Honest claim
True E2E (client key the server never holds)	only the user	"Not even we can read this" ✅
Encrypted at rest (operator holds the key)	operator, provider, breach-with-key, subpoena	"Encrypted & access-controlled" — NOT "even we can't read it"
Plaintext	anyone with DB/operator/breach access	be honest, or fix it

🔴 highest-tier content stored plaintext (🟠 if tightly access-controlled and not externally reachable). 🟠 encrypted-at-rest marketed as zero-knowledge (false claim — only true E2E earns it). Content the AI/server must read to function cannot be zero-knowledge — flag any plan claiming both; resolve per-field (encrypt what the server never reads; access-control the rest). 🟡 partial encryption: identity/contact fields (name, phone, email, dateOfBirth) left plaintext while medical/notes are encrypted → a DB breach still exposes who. Note it as a conscious tradeoff, not silent.

Check 4 — identity linkage & pseudonymity

Can sensitive content be joined back to a real identity (email/billing/phone)? Trace the FK / ownership column on each sensitive table. 🟠 "anonymous to the system / the AI" claimed, but content keys directly to the auth/billing identity → not structurally separated. True separation needs a pseudonymous content id + a restricted mapping table the content/AI layer can't read.

Check 5 — access-control reachability (verify, don't assume)

For each sensitive surface answer "who can actually reach this?" not "what does the policy say."

• RLS / row checks enabled on every sensitive table? Per-operation (no blanket FOR ALL)? Identity from the session, not the request body?
• Endpoint/function execution: who holds it? Is unauthenticated access possible via a default grant or a missing auth check?
• Second paths: a sensitive read reachable via an admin route, a report, an export, a cron job, a webhook, or a direct API call that skips the guarded UI path?
• App-level tenant isolation with no DB backstop (single DB role, ownership enforced only in code): flag every query on a tenant table that lacks the owner predicate — one miss = cross-tenant leak. (See the kit's RLS-hardening note for the centralized-scope fix.)

Check 6 — third-party & egress (where sensitive data leaves)

• 🟠 sensitive content sent to an external AI/processor (OpenAI/Anthropic/transcription/OCR) with no DPA/BAA, no retention/no-training assurance, no redaction layer → compliance gap (HIPAA/GDPR/local law).
• 🟡 PII in plaintext email/SMS/webhook bodies stored indefinitely by a third party (Resend/Twilio/etc.).
• 🟡 uploaded files stored at a public ACL when they should be private + proxied; signed-URL/CDN links that never expire and are persisted.
• 🟠 secrets/keys hardcoded, logged, or committed; tokens passed where they can be captured.
• 🟡 rate limiting that doesn't actually gate (in-memory per-instance on serverless → resets/forks; no shared store) on a public/auth/PII endpoint.

---

Output

Sensitive surfaces first. Per finding: 🔴/🟠/🟡/🟢 <check> — <finding> (file:line) → <fix>. Then a ranked must-fix list. A verified 🟢 clear is a valid result — don't manufacture findings.

Verify before you assert (and before you emit a gold pair)

Confirm every 🔴/🟠 against the actual source, not a pattern guess — read the handler, follow the enforcement, check for a guard elsewhere. Models routinely over-call IDOR/auth bugs that the code actually denies; a wrong "critical" handed to a repo owner burns trust. If a suspected finding is safe, record 🟢 clear (and with --gold, a false_alarm_of negative example). State your confidence; separate confirmed from suspected.

--gold emission

When --gold is set, after verification append one JSON line per verified finding (and per verified clear/dismissed claim) to .audit/gold-pairs.jsonl, per the kit README schema. Redact all secret values in snippet (keys, tokens, connection strings, PII samples → ‹redacted›) — these pairs are meant to be shareable. Stamp repo/commit from git (best-effort).