Trust — is it safe?
Brief 06

Security & Privacy Audit

A defensive review of your own codebase — auth gaps, injection surfaces, exposed secrets, and data leaks, ranked by exploitability.

SECURITY-AUDIT.md4 phases8 lenses~2.7k chars

Free & open · no signup · read-only — it ends by asking · nothing leaves your machine

What it does

You are working inside this repo. Mission: a defensive review of this codebase — find the weaknesses before someone else does, and rank them by exploitability × impact.

Read-only pass: inspect code and config, run audit tooling if available. Your only write is the report file.

What it looks for

8 lenses it looks through

Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.

1

Authorization gaps

endpoints missing checks, object-level access (can user A load user B's resource by ID?), role checks only in the UI

2

Injection surfaces

string-built SQL, unsanitized HTML rendering, shell/exec calls, path traversal on file access

3

Secrets

hardcoded keys, committed env files, secrets reaching the client bundle or logs

4

Sessions & tokens

storage location, expiry, invalidation on logout/password change

5

Input validation

trust boundaries where shape and bounds are assumed, not checked

6

Data exposure

verbose error messages, personal data in logs, API responses returning more than the UI needs

7

Dependencies

run the ecosystem's audit command; note critical/high findings

8

Config hygiene

permissive CORS, missing security headers, debug flags reachable in production

The deliverable

What lands in your repo

One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.

SECURITY-AUDIT.md
1
Posture summary
the honest three-sentence version
2
Findings
each: Name · Severity (critical/high/med/low) · Location · Risk scenario (1–2 lines) · Fix · Effort
3
Fix-this-week list
the top 3
4
Defaults to adopt
patterns that prevent whole classes (central authz, parameterized queries, secret scanning)
One file. Evidence-backed. It ends by asking before touching anything. · see a real SECURITY-AUDIT.md ↗
How it works

What it makes the agent do

Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.

1
Phase 1

Map the trust boundaries

Where does untrusted input enter.

2
Phase 2

Audit through 8 lenses

Cite file and line for every finding.

3
Phase 3

Curate

Severity = exploitability × impact.

4
Phase 4

Report

Create SECURITY-AUDIT.md at repo root.

Get started

Three ways to run this Goal Prompt

01 · COPY

Paste it in

Copy it and paste it into your agent inside the repo you want checked.

02 · INSTALL

As a slash command

Install the goal plugin once — two commands — then just type /goal:security-privacy-audit.

1/plugin marketplace add GhostlyGawd/goal-prompts
2/plugin install goal@goal-prompts

Or install only this Goal Prompt as /goal-security-privacy-audit:

curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=06 sh
03 · AGENT

From an agent (MCP)

Let an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.

https://goal-prompts.vercel.app/raw/06.md
Transparency

The exact prompt

Nothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.

Read the full brief (2,707 characters)
# Goal: Security & Privacy Audit

You are working inside this repo. Mission: a defensive review of this codebase — find the weaknesses before someone else does, and rank them by exploitability × impact.

Read-only pass: inspect code and config, run audit tooling if available. Your only write is the report file.

## Phase 1 — Map the trust boundaries
- Where does untrusted input enter: forms, APIs, uploads, webhooks, URL params?
- Where is auth enforced — and is it enforced in one place or re-implemented per route?
- What data here is sensitive: credentials, tokens, personal data, payment references?

## Phase 2 — Audit through 8 lenses
Cite file and line for every finding.
1. **Authorization gaps** — endpoints missing checks, object-level access (can user A load user B's resource by ID?), role checks only in the UI
2. **Injection surfaces** — string-built SQL, unsanitized HTML rendering, shell/exec calls, path traversal on file access
3. **Secrets** — hardcoded keys, committed env files, secrets reaching the client bundle or logs
4. **Sessions & tokens** — storage location, expiry, invalidation on logout/password change
5. **Input validation** — trust boundaries where shape and bounds are assumed, not checked
6. **Data exposure** — verbose error messages, personal data in logs, API responses returning more than the UI needs
7. **Dependencies** — run the ecosystem's audit command; note critical/high findings
8. **Config hygiene** — permissive CORS, missing security headers, debug flags reachable in production

## Phase 3 — Curate
- Severity = exploitability × impact; note the preconditions an attacker needs
- Keep the exploit description to the one or two lines needed to justify the fix — this is a defensive report
- Skip theoretical findings with no realistic path

## Phase 4 — Report
Create `SECURITY-AUDIT.md` at repo root:
1. **Posture summary** — the honest three-sentence version
2. **Findings** — each: Name · Severity (critical/high/med/low) · Location · Risk scenario (1–2 lines) · Fix · Effort
3. **Fix-this-week list** — the top 3
4. **Defaults to adopt** — patterns that prevent whole classes (central authz, parameterized queries, secret scanning)

Start the report with today's date. If `SECURITY-AUDIT.md` already exists from a previous run, read it first and lead with what changed since.

## Rules
- Their own severity labels must survive scrutiny — justify critical/high
- One systemic fix beats ten spot patches; say when that's the case
- If a `reports/` directory exists at the repo root, write the report there instead of the root.
- Before asking, present the top findings as a ranked list in plain words
- Report only — end by asking which fixes to make

House rules for this Goal Prompt

  • Their own severity labels must survive scrutiny — justify critical/high
  • One systemic fix beats ten spot patches; say when that's the case
  • If a reports/ directory exists at the repo root, write the report there instead of the root.
  • Before asking, present the top findings as a ranked list in plain words
  • Report only — end by asking which fixes to make
Keep exploring

More Trust briefs

Runs inside these playbooks — curated sequences you can launch with one paste: