| name | security-review |
| description | 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. |
| license | MIT |
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.
