# Security Review

> Perform application security reviews for web apps, APIs, backend services, frontend code, infrastructure/configuration, authentication/authorization flows, dependency changes, pull requests, and deployed application behavior. Use when Codex is asked to audit, assess, threat model, review for vulnerabilities, check secrets, verify access control, harden an app, or produce security findings with practical remediation.

- Skill: `breroz/security-review` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add breroz/security-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/breroz/security-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: BreRoz (https://skillmd.com/u/breroz)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/breroz/security-review

---


# Security Review

## Approach

Review like a practical attacker and a maintainer. Prioritize exploitable risks, missing controls, and unsafe defaults over theoretical issues. Ground every finding in code, config, route behavior, dependency behavior, or a clearly stated assumption.

For broad reviews, read `references/checklist.md` only after identifying the app stack and trust boundaries.

## Workflow

1. Scope the review:
   - Identify app type, exposed entry points, auth model, data stores, third-party services, background jobs, and deployment targets.
   - Note what is in scope and what cannot be verified locally.
   - Prefer repository evidence over guesses.

2. Map trust boundaries:
   - Public routes and APIs.
   - Authenticated user surfaces.
   - Admin or internal surfaces.
   - Webhooks, scheduled jobs, queues, file uploads, import/export paths, and integrations.
   - Secrets, environment variables, and generated artifacts.

3. Inspect high-risk areas first:
   - Authentication, session handling, password reset, email verification, account deletion.
   - Authorization and tenant/user ownership checks.
   - Admin endpoints, impersonation, sync/job triggers, billing, notification dispatch.
   - Database queries, input validation, file/path handling, SSRF-prone fetches, shell/subprocess usage.
   - Secret handling, logging, CORS/CSRF/clickjacking, rate limits, dependency/config risks.

4. Validate findings:
   - Trace data flow from attacker-controlled input to impact.
   - Check whether existing helpers/middleware already mitigate the issue.
   - Confirm with tests, local requests, or static evidence when feasible.
   - Avoid reporting issues that are blocked by a proven control.

5. Report findings first:
   - Order by severity.
   - Include file/line references when reviewing local code.
   - Explain impact, exploit preconditions, and a concrete fix.
   - Include residual risk or test gaps after findings.
   - If no issues are found, say so clearly and name the highest-risk areas reviewed.

## Severity

Use this scale:

- Critical: likely account/data compromise, auth bypass, remote code execution, unrestricted admin action, payment/security control bypass, or broad secret exposure.
- High: cross-user data access, stored XSS in sensitive contexts, privilege escalation, dangerous SSRF, broken reset/verification flows, serious injection.
- Medium: meaningful defense gap with plausible exploit path, missing rate limits on sensitive actions, CSRF on state-changing actions, weak security headers where impact is limited.
- Low: hardening, information exposure with limited sensitivity, logging hygiene, minor validation/config weaknesses.

## Output Format

Use a code-review stance by default:

- Findings first.
- Each finding should include severity, affected file/route/config, evidence, impact, and remediation.
- Then list open questions or assumptions.
- Then summarize what was reviewed and any tests/checks run.

For implementation tasks, fix the issue after confirming it is real, then run focused tests.

## Guardrails

- Do not dump secrets or sensitive values in the response. Redact any discovered secret.
- Do not run destructive tests or live exploitation against production systems unless the user explicitly asks and authorization is clear.
- Do not make broad dependency or framework claims without checking current docs when the detail is version-sensitive.
- Do not report generic best practices unless they connect to a real risk in this app.