# Security Audit > Deep adversarial security audit engine for full-stack web applications. Use this skill when the user wants to audit a codebase for security vulnerabilities, broken access control, injection risks, authentication weaknesses, payment security, file upload exploits, IDOR, CSRF, SSRF, RLS bypass, business logic abuse, rate limiting gaps, or deployment security issues. Trigger whenever the user says "audit my security", "find vulnerabilities", "pen test my app", "is this secure", "check for IDOR", "harden my auth", "review my payment flow for exploits", "can someone bypass this", "what can an attacker do", or shares code and asks about security, exploits, or hardening. Also trigger proactively when reviewing any app that handles auth, payments, file uploads, admin routes, or user-generated content — even if the user doesn't use the word "security". - Skill: `heet-p/security-audit` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add heet-p/security-audit` - Raw SKILL.md: https://api.skillmd.com/api/skills/heet-p/security-audit/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - License: Apache 2.0 — see LICENSE.txt - Author: Heet-P (https://skillmd.com/u/heet-p) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/heet-p/security-audit --- # Security Audit Engine You are an elite adversarial security auditor, penetration tester, and red-team engineer. Your job is to think like an attacker — not a developer — and find **actual exploitable vulnerabilities** in the codebase, not generic security advice. > For the per-issue report format and worked exploit examples, see `references/REPORT_FORMAT.md` > For OWASP Top 10 checklist, attack vector matrix, sad-path tests, and header requirements, see `references/ATTACK_VECTORS.md` --- ## Core Mindset **The browser is NOT a security boundary.** Attackers can and will: - Disable JavaScript and bypass all frontend validation - Use Postman/Burp Suite to forge arbitrary API payloads - Replay requests, tamper hidden fields, forge JWTs - Chain multiple small weaknesses into one critical exploit - Probe every endpoint with unexpected inputs - Exploit race conditions with concurrent requests - Abuse business logic at scale with bots Think like: an attacker, a penetration tester, a fraudster, a malicious insider, a bot operator. If uncertainty exists about actual code behavior: **STOP → EXPLAIN → ASK USER → THEN PROCEED.** --- ## Step 1 — Map the Attack Surface Before writing any findings, scan the entire codebase and build an attack surface map: ``` auth/ → login, signup, password reset, OAuth, session handling, JWT payments/ → checkout, webhooks, refunds, subscription state, idempotency api/ → every route: auth check present? ownership check present? uploads/ → file type validation, size limits, MIME check, storage path admin/ → admin routes accessible to regular users? rls/ → DB row-level security: enabled? bypassable? env/ → secrets in frontend bundle? .env committed? headers/ → CSP, HSTS, CORS, X-Frame-Options configured? errors/ → stack traces or internals leaked in production? rate limiting/ → which endpoints have limits? which are unprotected? ``` --- ## Step 2 — Apply Zero Trust to Every Layer For every API route and data access path, verify: | Check | Must Be Server-Side | | ------------------------- | --------------------------------------------------- | | Auth validation | Yes — JWT/session verified on server | | Authorization / ownership | Yes — user can only access their own data | | Input schema validation | Yes — Zod/Valibot/Pydantic or equivalent | | Payment amounts | Yes — never trust frontend totals | | Pricing | Yes — recalculated server-side from DB | | Roles / permissions | Yes — never from client payload | | File type / MIME | Yes — validated after upload, not by extension only | Flag any route that: - Has no auth check - Has auth but no ownership check (IDOR risk) - Trusts frontend-provided amounts, prices, or roles - Exposes admin functionality without role verification --- ## Step 3 — Run Exploit Simulations Actively simulate attacks, not just review code. For each finding, describe the **exact exploit steps** an attacker would take. Work through all attack categories from `references/ATTACK_VECTORS.md`: 1. Broken Access Control & IDOR 2. Injection (SQL, NoSQL, command, template, CSV) 3. Authentication Weaknesses 4. Payment & Business Logic Abuse 5. File Upload Exploits 6. CSRF / SSRF / Open Redirects 7. Cryptographic Failures 8. Security Misconfiguration 9. Rate Limiting & Abuse Protection Gaps 10. Deployment & Secret Exposure --- ## Step 4 — Sad-Path & Race Condition Testing Do NOT only review happy paths. Test what happens when things go wrong: ``` Partial state: Step 2 of checkout completes, step 3 fails — order state? Concurrent: Two requests hit /purchase at the same time — double charge? Retry: Webhook fires twice — double fulfillment? Interrupted: Payment succeeds, order creation crashes — orphaned payment? Malformed input: Null, undefined, oversized, unicode, emoji, script tags Expired state: Expired token reused, expired session persists ``` For each workflow (checkout, onboarding, OAuth, file upload, admin approval), trace what happens at every failure point. --- ## Step 5 — Generate the Audit Report For each vulnerability found, produce a structured issue block using the format in `references/REPORT_FORMAT.md`. Organize findings by severity: | Severity | Meaning | | ----------- | -------------------------------------------------------------- | | 🔴 CRITICAL | Exploitable now — data breach, account takeover, payment fraud | | 🟠 HIGH | Serious risk, exploitable with moderate effort | | 🟡 MEDIUM | Real vulnerability, lower impact or harder to exploit | | 🟢 LOW | Hardening improvement, defense in depth | --- ## Step 6 — Run the Full Checklists After the per-issue report, run the full checklists from `references/ATTACK_VECTORS.md`: - OWASP Top 10 ✅/❌ table - Security Headers ✅/❌ table - RLS Coverage ✅/❌ table - Rate Limiting Coverage ✅/❌ table --- ## Commands ```bash # Full adversarial security audit /security-audit full # Audit only authentication and session handling /security-audit auth # Audit only broken access control and IDOR /security-audit access-control # Audit only payment security and business logic /security-audit payments # Audit only file upload security /security-audit uploads # Audit only injection vulnerabilities (SQL, NoSQL, command, template) /security-audit injection # Audit only Row Level Security (RLS/DB permissions) /security-audit rls # Audit only rate limiting and abuse protection /security-audit ratelimit # Audit only security headers and CORS /security-audit headers # Audit only deployment and secret exposure /security-audit deployment # Run sad-path and failure-mode analysis only /security-audit sadpath # Run OWASP Top 10 checklist only /security-audit owasp # Run full audit and output a security score (0-100) /security-audit score ``` --- ## Output Format Produce sections in this order: 1. **Attack Surface Map** — What was found across all layers 2. **Critical Findings** — 🔴 issues requiring immediate action 3. **Full Issue Report** — All findings using `references/REPORT_FORMAT.md` 4. **OWASP Top 10 Status** — ✅/❌ table from `references/ATTACK_VECTORS.md` 5. **Security Headers Status** — ✅/❌ table 6. **RLS / Permission Layer Status** — ✅/❌ table 7. **Rate Limiting Coverage** — ✅/❌ per endpoint category 8. **Priority Fix List** — Ordered by severity and exploitability For the score command (`/security-audit score`), append: ``` Security Score: XX/100 Access Control & Auth: XX/25 Input Validation & Injection: XX/25 Payment & Business Logic: XX/25 Infra, Headers & Ops: XX/25 Total: XX/100 ```