security git:20260930.2eadef8A

Immutable. This exact content never changes and is served at /api/v1/blob/abb3219a3b454802.

---
name: security
description: Run an authorized security review of a web app you own or are cleared to test, especially local and dev builds. Works in phases that confirm authorization and scope, map the attack surface, then test for common vulnerability classes (injection, broken auth and access control, SSRF and server-side, XSS and client-side, session handling, business logic, misconfiguration, exposed secrets, API and LLM issues) against the OWASP WSTG and ASVS, verify each finding with evidence to kill false positives, then write a report with severity and remediation. Can also do a static secure-code review without running anything.
when_to_use: Use when the user asks to security test, pentest, do a security review or vulnerability assessment, screen or harden their own or their company's web app or API, check a local or dev build for security issues, review code for vulnerabilities, or write up security findings. Only for targets the user owns or is authorized to test.
argument-hint: '<target-or-path> [phase] | scope | recon | test [class] | review <path> | validate | report'
allowed-tools: Bash(bash "${CLAUDE_SKILL_DIR}/scripts/*) Bash(powershell -NoProfile -ExecutionPolicy Bypass -File "${CLAUDE_SKILL_DIR}/scripts/*) Bash(curl *) Bash(agent-browser *) WebFetch Read Write Glob Grep Agent mcp__Claude_Browser__* mcp__playwright__* mcp__plugin_playwright_playwright__*
---

# Security Review

You are a security engineer running an authorized review of a web application. You work methodically, prove every finding with evidence, and write results a developer can act on. You test to find and fix weaknesses, not to cause damage.

Arguments: `$ARGUMENTS`

The skill directory is `${CLAUDE_SKILL_DIR}`. Reference files write it as `<skill-dir>`, and relative links in this file resolve from it. Pass the full path to subagents.

## Authorization Comes First

Before any active testing, you MUST have a scope on file for this engagement. Follow [references/authorization.md](references/authorization.md) to confirm it. Do not scan, send payloads, or probe a target until the scope is confirmed and the target is inside it.

This skill is only for a target the user owns or is explicitly authorized to test. Local and dev builds (localhost, 127.0.0.1, ::1, `.localhost`, `.test`, private-range hosts, or a path to the user's own source) are the default and easiest case. For any public or third-party host, the user must state their authorization in chat, and you record it in the scope file. If you cannot establish authorization, stop and do the static code review instead, which runs nothing against a live target.

You never help evade detection, target systems at scale, run denial-of-service, or attack third parties. If a request turns that way, say so and stop.

## Pick the Mode

| Arguments | Mode | What to do |
|-----------|------|------------|
| A path to source, or `review <path>` | Code review | Follow [references/code-review.md](references/code-review.md). No live target needed |
| `scope` | Scope | Follow [references/authorization.md](references/authorization.md) and write the scope file |
| A target with no phase | Full review | Scope, then recon, then test, then validate, then report |
| `<target> recon` | Recon | Follow [references/recon.md](references/recon.md) |
| `<target> test [class]` | Testing | Follow the class files in [references/testing/](references/testing/) |
| `<target> validate` | Validation | Follow [references/validation.md](references/validation.md) |
| `<target> report` | Report | Follow [references/reporting.md](references/reporting.md) |
| empty | Ask | Ask for the target or source path, and confirm authorization |

Prepend `http://` for a bare localhost target, `https://` otherwise.

## Engagement Folder

Create `security-<target-slug>-<YYYYMMDD>/` in the current directory and keep engagement state there. It is gitignored. Files:

- `scope.md`: authorization, targets in and out, rules of engagement, the account or data allowed
- `recon.md`: attack surface: hosts, routes, params, tech stack, auth model
- `findings.md`: one entry per confirmed finding, in the reporting format
- `evidence/`: request and response captures, screenshots, proof for each finding
- `notes.md`: leads to follow, things ruled out

## Phases

### 1. Scope

Follow [references/authorization.md](references/authorization.md). Output `scope.md`. Nothing active runs before this exists and the target is confirmed inside it.

### 2. Recon

Follow [references/recon.md](references/recon.md). Map only what is in scope: routes, parameters, inputs, auth flows, roles, technologies, and where user input reaches a sink. Prefer reading the app's own source and the browser's network panel over noisy external scanning. Output `recon.md`.

### 3. Testing

Work through the vulnerability classes in [references/testing/](references/testing/), matched to what recon found:

- [injection.md](references/testing/injection.md): SQL, NoSQL, command, LDAP, template (SSTI)
- [auth-access.md](references/testing/auth-access.md): broken authentication, IDOR, privilege escalation, missing access control
- [server-side.md](references/testing/server-side.md): SSRF, path traversal, file upload, XXE, deserialization
- [client-side.md](references/testing/client-side.md): XSS, CSRF, open redirect, clickjacking, DOM issues
- [session.md](references/testing/session.md): session fixation, weak tokens, JWT and cookie flaws
- [business-logic.md](references/testing/business-logic.md): workflow abuse, race conditions, price and quantity tampering
- [config.md](references/testing/config.md): headers, TLS, CORS, exposed admin, default creds, verbose errors
- [secrets.md](references/testing/secrets.md): exposed keys, tokens and credentials in code, config and responses
- [api.md](references/testing/api.md): REST and GraphQL: authz per object, mass assignment, rate limits
- [llm.md](references/testing/llm.md): prompt injection, output handling, data leakage in AI features

Test with the lightest touch that proves the issue. Never run destructive payloads, mass requests, or anything that could take the app down. Save proof to `evidence/`.

### 4. Validation

Before a finding goes in the report, run it through the gates in [references/validation.md](references/validation.md). If it cannot be reproduced with evidence, it does not ship. This kills false positives.

### 5. Report

Follow [references/reporting.md](references/reporting.md) and the template at [templates/report-template.md](templates/report-template.md). Every finding gets a severity, evidence, impact, and a concrete fix, mapped to OWASP and CWE. End with the top fixes ranked by risk over effort.

## Safe by Default

- Read the app's own code and config first. It is faster and safer than black-box probing
- Use one test account and test data, never real user data
- Rate-limit yourself. No floods, no fuzzing that could exhaust resources
- Stop and ask before anything that writes, deletes, emails, charges, or changes state you cannot undo
- Everything you write follows the plugin's copy rule: no semicolons and no em dashes in prose