Security review
Audit the application's code for real vulnerabilities — frontend and backend — and hand back a prioritized, safe-to-apply plan. The goal is to shrink the attack surface without changing what a legitimate user sees or breaking the app.
Read first (always)
List learnings/ and read anything relevant. Reuse, don't re-derive:
- The always-on blocker set applied to every PR lives in
../reviewing-code/references/security-checks.md (PII in logs, injection, HMAC/signature, the AI-generated-code lens). Apply it — don't re-list it.
- The build-time prevention rules live in
../developing-features/references/security.md (auth/session, DB least-privilege, TLS, supply chain, and the full AI/LLM guardrails) and ../developing-features/references/untrusted-content.md (prompt injection).
- This skill adds the OWASP-2025 breadth, the frontend / infra / privacy gaps, and the safe-remediation protocol (see
references/).
How to run a security review
- Scope it. What are you auditing — a PR, a feature, the whole app? What's the stack (framework, DB, auth provider, does it use AI)? Read
AGENTS.md/README and grep the code to map the inputs, auth checks, persistence, external calls, and any AI/LLM surface.
- Go by priority, top-down (
references/owasp-2025-checklist.md): CRITICAL (secrets, broken access control / IDOR, injection, password storage) → HIGH (auth/session, security headers, CORS/CSRF, crypto, supply chain) → MEDIUM (misconfiguration, error handling, file upload, API mass-assignment, logging/alerting) → privacy (LGPD/GDPR) → continuity (backups).
- Report findings — don't blind-fix. For each: severity, the exact risk, the concrete fix, and how to verify it caused no regression. Prove access-control findings (logged in as user A, try user B's resource).
- Fix under the anti-regression protocol (
references/safe-remediation.md): one change per branch/commit, backup before DB changes, test the legitimate flow before and after, report-only rollout for CSP/rate-limit, transparent re-hash for password migration, staging before prod, fail closed.
The one principle under all of it
Never mix user data with command/structure — parametrize, escape, or allow-list at the right interpreter (DB, shell, template, browser, AI model). Enforce authorization server-side on every request, keep secrets off the client, and fail closed. Every rule below is an application of these.
Output
A prioritized report: findings grouped Critical / High / Medium, each with what's wrong · why it matters · how to fix safely · how to verify no regression, ending with the smallest first step. This is a review — never run git or deploy; the human applies the fixes.
Capture a learning
If you find a project-specific vulnerability class or a fix that needed a special rollout, append a learnings/YYYY-MM-DD-slug.md (or use /learn).
See also
references/owasp-2025-checklist.md — the full frontend + backend + privacy checklist (OWASP Top 10 2025 + API Top 10).references/safe-remediation.md — apply security fixes without breaking the app.skills/threat-modeling — design-time: what could go wrong before building.skills/reviewing-code — the always-on security blockers in a normal PR.../developing-features/references/security.md — build-time prevention; ../developing-features/references/untrusted-content.md — prompt-injection guardrail.
1---2name: security-review3description: Review an application's code for security across frontend AND backend and produce a prioritized, safe-to-apply remediation plan — OWASP Top 10 (2025), OWASP API Top 10, plus privacy (LGPD/GDPR). Use when the user asks for a "security review", "security audit", "harden this", "is this secure?", "check for vulnerabilities", "OWASP", "pentest-style review", or wants a focused security pass on a feature/PR/app (secrets, access control, injection, auth/session, headers/CORS/CSRF, file upload, supply chain, logging, privacy). Applies a strict anti-regression protocol so fixes don't break the app. For designing security up front use threat-modeling; for the always-on security blockers in a normal PR use reviewing-code.4license: MIT5---67# Security review89Audit the application's code for real vulnerabilities — frontend and backend — and hand back a prioritized, **safe-to-apply** plan. The goal is to shrink the attack surface **without changing what a legitimate user sees or breaking the app**.1011## Read first (always)1213List `learnings/` and read anything relevant. **Reuse, don't re-derive:**1415- The **always-on blocker set** applied to every PR lives in `../reviewing-code/references/security-checks.md` (PII in logs, injection, HMAC/signature, the AI-generated-code lens). Apply it — don't re-list it.16- The **build-time prevention rules** live in `../developing-features/references/security.md` (auth/session, DB least-privilege, TLS, supply chain, and the full AI/LLM guardrails) and `../developing-features/references/untrusted-content.md` (prompt injection).17- This skill adds the **OWASP-2025 breadth**, the **frontend / infra / privacy gaps**, and the **safe-remediation protocol** (see `references/`).1819## How to run a security review20211. **Scope it.** What are you auditing — a PR, a feature, the whole app? What's the stack (framework, DB, auth provider, does it use AI)? Read `AGENTS.md`/README and grep the code to map the inputs, auth checks, persistence, external calls, and any AI/LLM surface.222. **Go by priority, top-down** (`references/owasp-2025-checklist.md`): **CRITICAL** (secrets, broken access control / IDOR, injection, password storage) → **HIGH** (auth/session, security headers, CORS/CSRF, crypto, supply chain) → **MEDIUM** (misconfiguration, error handling, file upload, API mass-assignment, logging/alerting) → **privacy (LGPD/GDPR)** → **continuity (backups)**.233. **Report findings — don't blind-fix.** For each: severity, the exact risk, the concrete fix, and how to verify it caused no regression. Prove access-control findings (logged in as user A, try user B's resource).244. **Fix under the anti-regression protocol** (`references/safe-remediation.md`): one change per branch/commit, backup before DB changes, test the legitimate flow before and after, report-only rollout for CSP/rate-limit, transparent re-hash for password migration, staging before prod, fail closed.2526## The one principle under all of it2728Never mix **user data** with **command/structure** — parametrize, escape, or allow-list at the right interpreter (DB, shell, template, browser, AI model). Enforce **authorization server-side on every request**, keep **secrets off the client**, and **fail closed**. Every rule below is an application of these.2930## Output3132A prioritized report: findings grouped **Critical / High / Medium**, each with *what's wrong · why it matters · how to fix safely · how to verify no regression*, ending with the smallest first step. This is a review — **never run git or deploy**; the human applies the fixes.3334## Capture a learning3536If you find a project-specific vulnerability class or a fix that needed a special rollout, append a `learnings/YYYY-MM-DD-slug.md` (or use `/learn`).3738## See also3940- `references/owasp-2025-checklist.md` — the full frontend + backend + privacy checklist (OWASP Top 10 2025 + API Top 10).41- `references/safe-remediation.md` — apply security fixes without breaking the app.42- `skills/threat-modeling` — design-time: what could go wrong *before* building.43- `skills/reviewing-code` — the always-on security blockers in a normal PR.44- `../developing-features/references/security.md` — build-time prevention; `../developing-features/references/untrusted-content.md` — prompt-injection guardrail.
Cristhianzl