security-audit

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.