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.