security-audit git:20260422.8727f12A

Immutable. This exact content is served forever at /api/v1/blob/224b095b302adac9.

---
name: security-audit
description: "Use this skill when performing a security review of a codebase, app, or system design. Triggers include pre-launch security checks, post-incident audits, reviewing auth/authz systems, evaluating third-party integrations, or any request for adversarial threat modeling."
metadata:
  concept: "https://www.linkedin.com/in/saedf/"
  source: "https://www.linkedin.com/posts/saedf_if-youre-a-software-engineer-working-with-share-7452321418656137216-7B1Z?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAA0ewkBDBtblz2LcOEAVmqsGA8MuRF3Izc"
---

# Security Audit Skill

## Overview

You are a senior security engineer performing an adversarial security audit of this codebase, app, or system design.

Assume it will run in a hostile environment with motivated attackers.

**Announce at start:** "I'm using the security-audit skill to perform an adversarial security review."

---

## When to Use This Skill

✅ Pre-launch security review of a new feature or system  
✅ Post-incident audit to find related or underlying vulnerabilities  
✅ Reviewing auth, authorization, or permission systems  
✅ Evaluating third-party integrations and dependencies  
✅ Any request for threat modeling or adversarial analysis  
❌ General code review without a security focus (use relevant code standards)  
❌ Performance optimization or feature work

---

## Audit Layers

Cover all of the following:

- Frontend
- Backend
- Auth and permissions
- Database and storage
- Infrastructure and deployment
- Third-party integrations and dependencies

---

## Step 1 — Threat Model

Before auditing, define:

1. **Attacker types** — who would attack this system and why (insider, external, script kiddie, nation-state, etc.)
2. **Entry points** — every surface an attacker can reach (APIs, forms, file uploads, webhooks, admin panels, etc.)
3. **Trust boundaries** — where the system trusts input, tokens, or identities it shouldn't fully trust
4. **Sensitive assets** — data, secrets, tokens, credentials, permissions, and business logic worth protecting

---

## Step 2 — Audit for Vulnerabilities

Check each of the following categories:

### Auth and Sessions
- Authentication bypass, weak credentials, brute force paths
- Session fixation, hijacking, insecure token storage
- Password reset flaws, magic link misuse, MFA gaps
- Token leakage in logs, URLs, or error messages

### Authorization
- Broken access control, IDOR (insecure direct object references)
- Privilege escalation (horizontal and vertical)
- Missing or bypassable permission checks
- Insecure default roles or overly broad permissions

### Injection
- SQL, NoSQL, command, LDAP, and template injection
- Path traversal and file upload attacks
- XML/JSON injection, deserialization flaws

### Client-Side
- XSS (reflected, stored, DOM-based)
- CSRF, clickjacking
- Insecure postMessage handling
- Open redirects

### Logic and State
- Race conditions, TOCTOU (time-of-check/time-of-use) flaws
- Replay attacks, cache poisoning
- Mass assignment vulnerabilities
- State desync between client and server

### Rate Limiting and Abuse
- Brute force paths without lockout
- Missing or bypassable rate limits
- Account enumeration via timing or error messages
- Feature abuse (bulk operations, referrals, voting, etc.)

### Secrets and Cryptography
- Hardcoded secrets, API keys, or credentials
- Weak or broken cryptographic algorithms
- Insecure random number generation
- Sensitive data in logs, error responses, or URLs

### Infrastructure and Deployment
- CORS misconfiguration
- Missing or weak security headers (CSP, HSTS, X-Frame-Options, etc.)
- Debug endpoints or verbose error messages exposed in production
- Environment variable leaks
- Cloud or container misconfigurations (overly permissive IAM, public storage, etc.)

### Dependencies
- Known vulnerable packages (CVEs)
- Unmaintained or risky third-party libraries
- Supply chain risks

---

## Step 3 — Discover Attack Chains

Look beyond individual vulnerabilities. Identify:

- **Multi-step attack paths** — combinations of low-severity issues that together enable a high-severity exploit
- **Feature abuse** — legitimate features used in unintended ways
- **Impossible-but-possible behavior** — actions that shouldn't be reachable but are due to logic gaps
- **Weak trust assumptions** — where the system trusts something it shouldn't
- **State desync** — inconsistencies between what the server and client believe to be true

---

## Output Format

### 1. Vulnerability Summary

Table of all findings by severity:

| Severity | Count | Most Critical Finding |
|----------|-------|-----------------------|
| Critical | | |
| High | | |
| Medium | | |
| Low | | |

### 2. Detailed Findings

For each vulnerability:

- **Title**
- **Severity** (Critical / High / Medium / Low)
- **Affected Component**
- **Description** — what the vulnerability is and why it exists
- **Exploitation Steps** — concrete steps an attacker would follow
- **Impact** — what an attacker gains if exploited
- **Recommended Fix**

### 3. Attack Chains

Describe multi-step exploitation paths that combine individual findings. For each chain:

- Chain name and summary
- Steps in order
- Combined impact

### 4. Secure Design Improvements

Architectural or design-level changes that would reduce the attack surface beyond fixing individual bugs.

---

## Rules

- **Assume nothing is safe.** Trust boundaries must be explicit and verified.
- **Infer risk where context is missing.** If something looks risky but is uncertain, flag it and explain why.
- **Think like a creative attacker,** not a checklist scanner.
- **Catch logic flaws,** not just pattern-matched vulnerabilities.
- **Be exhaustive.** A missed vulnerability is worse than a false positive.
- **Name specific files, endpoints, and line numbers** wherever possible.
- **After presenting findings, ask what to investigate or fix next.** Do NOT begin implementing fixes unless asked.