Security harden

Security Hardening Playbook

Authored by Claude Fable 5 for authorized, defensive security work only — reviewing your own project, an app you're building, or a codebase you have permission to test. If the request is about attacking systems you don't own, stop.

Why this exists

Security scans by unguided models produce two failure modes, both harmful: a flood of theoretical "best practice" nags that bury the one real bug, and confident claims of vulnerabilities that don't actually exploit (crying wolf destroys trust and wastes the user's time). This playbook demands a working threat model up front and proof of exploitability before anything is called a vulnerability. Unproven concerns are labeled as such, separately.

Phase 0 — Threat model (what are we actually protecting?)

Read CLAUDE.md and the code enough to answer:

• What's the sensitive stuff? Secrets/keys, user data, auth tokens, payment info, PII.
• What's the trust boundary? Where does untrusted input enter — client requests, URL params, file uploads, third-party webhooks, env at build time?
• Who's the attacker? Anonymous internet user, authenticated-but-malicious user, someone who reads the shipped client bundle?

Write a 4-line threat model. Every finding must map to it: an issue nobody in your threat model can reach is a Phase-3 "note," not a vulnerability.

Phase 1 — Highest-signal checks first

Order matters — check the things that are both common and catastrophic before the exotic ones. Go through these in order, recording each hit as file:line:

1. Secret leakage. Grep for API keys, tokens, passwords in source, in client-shipped code (anything with a client-exposed prefix like VITE_, NEXT_PUBLIC_, REACT_APP_), and in committed .env files. A provider secret in a client bundle is the single most common real breach. Verify: is this value actually reachable in the built client, or server-only?
2. AuthN/AuthZ gaps. For each endpoint/route/data operation: is it authenticated? Is it authorized (can user A read user B's data by changing an ID)? Insecure direct object references are everywhere and trivially exploitable.
3. Injection. Untrusted input flowing into: SQL/NoSQL queries, shell commands, HTML (XSS), file paths (traversal), redirects. Trace the input from entry to sink.
4. Data-store rules. If using Firestore/Supabase/etc., read the security rules. Client-side checks are not security if the rules allow direct access.
5. Dependency risk. Check for known-vulnerable dependencies (npm audit or equivalent) — but triage: a vuln in a dev-only or unreachable path is lower priority than a reachable one.
6. Transport & headers. HTTPS everywhere, sensible CORS (not * on credentialed endpoints), no secrets in URLs/logs.

Phase 2 — Prove it before you call it

For every candidate from Phase 1, do one of:

• Trace the exploit path end to end in the code and describe the concrete attack: "an unauthenticated user sends POST /api/x with id set to another user's id and receives their notes because the handler never checks ownership (api/x.ts:34)."
• Demonstrate it if you safely can in a local/authorized environment (e.g. a request that returns data it shouldn't). Never test against production or systems you lack permission for.

If you cannot construct a concrete path, it does not go in the vulnerabilities list. It goes in "unverified concerns" with a note on what you'd need to confirm it. This distinction is the core discipline of the skill — a proven bug and a hunch are not the same finding.

Phase 3 — Report

# Security Review — <project> — <date>

## Threat model
<the 4 lines>

## Confirmed vulnerabilities (proven exploitable)
### Critical / High / Medium (order by real-world impact)
- **<title>** — `file:line`
  - **Exploit:** <the concrete path an attacker takes>
  - **Impact:** <what they get>
  - **Fix:** <specific change; least-privilege, defense-in-depth>

## Unverified concerns (couldn't prove; worth checking)
- <item> — what would confirm or dismiss it

## Good practices already in place
<so a fix doesn't remove an existing protection>

Phase 4 — Fix plan, then stop

Propose fixes ordered by (impact × ease). For each, describe the change and any risk it carries. Do not apply fixes automatically unless the user asks — security changes (auth logic, rules files) can lock out real users if wrong, so the user decides what and when. Never write code whose purpose is to attack, evade detection, or exfiltrate; this skill hardens, it does not arm.