owasp-security

Files (5)

• SKILL.md
• config-and-supply-chain.md · reference/
• languages.md · reference/
• owasp-report.md · reference/
• review-checklist.md · reference/

SKILL.md (first lines)

# OWASP Security

Apply these standards when writing or reviewing code. For a review, follow the workflow below.

**Reference files** (read the one the task needs, and only the section you need):
- [`reference/review-checklist.md`](reference/review-checklist.md): coverage checklist for every Top 10 category, plus LLM and agent checks. Read during step 3 of a review.
- [`reference/languages.md`](reference/languages.md): per-language pitfalls with unsafe/safe examples for 20+ languages. Read the section for the language under review.
- [`reference/config-and-supply-chain.md`](reference/config-and-supply-chain.md): A02 and A03 in Dockerfiles, Kubernetes, Terraform, framework config, security headers, lockfiles, and CI/CD. Read when the change touches config, IaC, dependencies, or pipelines.
- [`reference/owasp-report.md`](reference/owasp-report.md): attack vectors, mitigations, and worked examples for every Top 10:2025, ASVS 5.0, LLM Top 10, and Agentic item. About 1100 lines: jump to the section you need.

## Security Review Workflow

Copy this checklist into your response and tick it off as you go:

```
Security Review Progress:
- [ ] Step 1: Map entry points and trust boundaries
- [ ] Step 2: Load the references this code needs
- [ ] Step 3: Sweep for candidate issues
- [ ] Step 4: Triage every candidate
- [ ] Step 5: Report findings
```

**Step 1: Map entry points and trust boundaries.** List where attacker-controlled data enters:
routes and handlers, headers and cookies, uploads, webhooks, queue consumers, CLI arguments,
third-party API responses, and anything an LLM reads or returns. Note where authentication and
authorization are enforced; it is often centralized in middleware rather than per route.

**Step 2: Load the references this code needs.** The language section of `languages.md`;
`config-and-supply-chain.md` if config, IaC, dependencies, or CI changed; the LLM and Agentic
sections of `owasp-report.md` if the code calls a model or runs an agent.

**Step 3: Sweep for candidate issues.** Walk `review-checklist.md` for the categories the code
touches. For each candidate, trace the path from an entry point in step 1 to the sink.

**Step 4: Triage every candidate** with the rubric in "Before Reporting a Finding" below. Drop
candidates that fail it, or downgrade them to defense-in-depth. If a candidate's reachability
is unclear, go back to step 1 for that input before deciding.

**Step 5: Report findings** in the format below, highest severity first.

## Before Reporting a Finding

A pattern match is not a vulnerability. The most common failure mode in automated security
review is reporting unreachable or already-mitigated code, which buries the real findings.
Confirm all four before reporting:

1. **Is the input actually attacker-controlled?** Trace it back to a real entry point: a
   request parameter, header, cookie, uploaded file, webhook, queue message, or third-party
   API response. A value that only ever comes from a constant, an enum, or trusted internal
   config is not an injection source.
2. **Is the sink reachable with that input?** Check whether validation, an allowlist, an ORM,
   or a framework-level control already sits between them. Look for auth middleware
   (`middleware.ts`, `proxy.ts`, Express/Django/Rails middleware, a base controller,
   decorators) before flagging a route as missing authorization. Enforcement is often
   centralized rather than per-route.
3. **What is the blast radius?** Who can trigger it, what do they get, and does it cross a
   trust boundary? An SSRF reaching cloud metadata differs from one reaching localhost only.
4. **Can the attacker perform every step?** Each step of the exploit must be possible from
   the attacker's position. A symlink race needs a way to create symlinks on the server; a
   header attack needs a client that can set that header. If a step needs a capability the
   code doesn't show the attacker having, the finding is "Needs verification", not High.

Report severity by exploitability, not by pattern. State the concrete path (*this input
reaches this sink*) and say so explicitly when a finding is theoretical or defense-in-depth
rather than directly exploitable. If reachability can't be determined from the code available,
say that instead of asserting either way.

## Reporting Format

One block per finding, highest severity first:

```
[SEVERITY] Title (CWE-###, OWASP A##:2025, LLM## Risk Name, ASI## Risk Name)
Location:   path/to/file.ext:LINE
Path:       <entry point> -> <intermediate hops> -> <sink>
Impact:     who can trigger it, what they get, which trust boundary it crosses
Fix:        the concrete change, with a code snippet when it isn't obvious
Confidence: Confirmed | Likely | Needs verification (say what you couldn't see)
```

Write every LLM and ASI ID with its risk name, e.g. "LLM03 Excessive Agency". A bare LLM ID is
ambiguous: the 2025 and 2026 editions use the same numbers for different risks.

| Severity | Meaning |
|---|---|
| Critical | Unauthenticated remote code execution, auth bypass, or mass data exposure |
| High | Authenticated exploitation crossing a trust boundary (IDOR into other tenants, SQLi behind login) |
| Medium | Needs unusual preconditions, or impact is limited to the attacker's own data |
| Low | Defense-in-depth gap with no demonstrated exploit path |
| Info | Hardening suggestion; say plainly that it is not a vulnerability |

If the review finds nothing exploitable, say so directly. Do not pad the report with Info items
to look thorough; a long list is what makes real findings get ignored.

## OWASP Top 10:2025

Three categories were renamed from 2021 and two are new (A03, A10). Use these names and
numbers; much OWASP material online still cites the 2021 list.

| # | Category | Key Prevention |
|---|----------|----------------|
| A01 | Broken Access Control (now includes SSRF) | Deny by default, enforce server-side, verify ownership |
| A02 | Security Misconfiguration | Harden configs, disable defaults, minimize features |
| A03 | Software Supply Chain Failures | Lock versions, verify integrity, audit dependencies |
| A04 | Cryptographic Failures | TLS 1.2+, AES-256-GCM, Argon2/bcrypt for passwords |
| A05 | Injection | Parameterized queries, input validation, safe APIs |
| A06 | Insecure Design | Threat model, rate limit, design security controls |
| A07 | Authentication Failures | MFA, check breached passwords, secure sessions |
| A08 | Software or Data Integrity Failures | Sign packages, SRI for CDN, safe serialization |
| A09 | Security Logging and Alerting Failures | Log security events, structured format, alerting |
| A10 | Mishandling of Exceptional Conditions | Fail-closed, hide internals, log with context |

## OWASP Top 10 for LLM Applications (2026)

For applications that call LLMs (chatbots, RAG, copilots, agents). The 2026 edition renumbered
the list; translate 2025 IDs with the table in `owasp-report.md` and cite 2026 IDs only.

| # | Risk | Key Mitigation |

From agamm/claude-code-owasp, MIT.