security-auditlisted

# Security Audit ## Overview An audit is **an adversarial proof about a specific attack surface**, not a checklist walk. A checklist produces "no hardcoded secrets found ✅". An audit produces "signed-in user B can increment their own `reputationScore` via `PATCH /users/B` because rule line 88 blocks the field only on `diff()`, and `create` does not check it at all — here is the request, here is the result." One is a claim. The other is evidence. **The audit is only as good as its weakest surface.** A perfect review of Firestore rules is worth little if one unauthenticated callable leaks the same data. So: enumerate the whole surface first, then prove each piece, then report coverage honestly. ## The Iron Laws **1. No finding without evidence you personally read.** Every finding cites `file:line` from a file you opened in this session. Not from memory, not from a doc in the repo, not from a pattern you assume is there. If you did not read it, it does not go in the report. **2. No finding without an exploit path.** State: *who* (anonymous / any signed-in user / a specific other user / admin), *what they send*, and *what they get*. If you cannot write that sentence, you have a code smell, not a finding — file it under Hardening, not under a severity. **3. No severity without the rubric.** Severity comes from the table in this skill, not from vibes. "Feels bad" is not High. **4. Verified or labelled.** Every finding is `CONFIRMED` (you reproduced it — emulator, test, or