pekral/security-review

Constraints

• Apply @rules/php/core-standards.mdc
• Apply @rules/php/dependency-selection.mdc — when the audit recommends replacing a vulnerable package with a hardened alternative, run the Activity gate + Compatibility gate on the proposed replacement before recommending the swap. Never trade a vulnerable-but-maintained package for an archived / abandoned / branch-pinned one in the name of security.
• Apply @rules/code-review/general.mdc
• Apply @rules/security/backend.mdc
• Apply @rules/code-review/frontend.mdc
• Apply @rules/code-review/mobile.mdc
• If the current project uses Laravel, also apply @rules/laravel/laravel.mdc, @rules/laravel/architecture.mdc, @rules/laravel/filament.mdc, and @rules/laravel/livewire.mdc
• Apply @rules/reports/general.mdc. When the audit findings are folded into the GitHub PR comment by a CR wrapper, they stay in canonical English per the rule's Exception — technical CR findings on the GitHub PR. When a non-technical summary is published on a linked issue / JIRA ticket via @skills/pr-summary/SKILL.md, it follows the language of the source assignment. CVE / CWE / OWASP identifiers and code identifiers stay verbatim regardless of the surrounding prose language.
• Focus on realistic, exploitable issues
• Never reveal secrets
• Read-only skill — never modify code, never stage / commit / push changes, and never run any git write operation (git add, git commit, git push, git reset, git checkout -- …, etc.). Switching to the relevant branch and git pull to read the latest diff are allowed; mutating the working tree or pushing to the remote is not. Output is the audit report only.

Scope

Perform a focused security review with emphasis on:

• real exploitability
• business logic flaws
• missing authorization
• unsafe data flows

Avoid generic best-practice noise.

---

Core Checks

Input & Injection

• SQL / command injection
• XSS (stored, reflected, DOM)
• unsafe deserialization

Authentication & Access Control

• missing authorization (IDOR / BOLA)
• privilege escalation
• broken access control

Data Exposure

• sensitive data leaks (API, logs, errors)
• unsafe error messages (stack traces, paths, DB details)

External Interaction (APIs & SSRF)

• outbound requests with user-controlled input
• missing domain allowlists
• access to internal/private IPs
• dangerous protocols (file://, gopher://, etc.)
• missing validation after redirects
• missing rate limiting or abuse protection
• third-party API contract — when the diff integrates with a third-party API or service, verify the security-critical aspects of the implementation against the public API documentation: authentication and scope handling, signature/webhook verification, idempotency and retry semantics, error envelopes, and rate-limit handling. Functional alignment with the issue assignment is owned by @skills/code-review/SKILL.md — do not duplicate it here.

File Handling

• unsafe uploads (extension, MIME, signature)
• path traversal
• execution risk (files in webroot)

Dependencies & Configuration

• vulnerable packages (composer.lock, composer audit)
• unsafe configuration (uploads, execution, credentials)

Queues & Background Jobs

• retry abuse
• non-idempotent operations
• unsafe external calls

---

Prioritization

• Focus on issues that are:
  • exploitable in real scenarios
  • impactful (data access, privilege escalation, RCE)
• Deprioritize theoretical or low-impact findings

---

Report

Severity

• Critical
• High
• Medium
• Low

Each finding must include

• severity
• category (OWASP)
• location (file + line)
• description
• exploit scenario
• recommended fix

Reproducer fields (mandatory for Critical and High)

• Faulty Example — minimal code snippet or attacker payload that reproduces the vulnerability (redact secrets, tokens, and PII)
• Expected Behavior — single assertable security guarantee (rejection, authorization denial, escaped output, no side effect)
• Test Hint — one sentence pointing at the test layer (unit, feature, HTTP) and entry point
• Suggested Fix — minimal corrected code snippet that closes the vulnerability (parameterized query, authorization check, output escaping, signature verification, safer SDK call, etc.). Must comply with @rules/php/core-standards.mdc, @rules/security/backend.mdc, and, for Laravel projects, @rules/laravel/architecture.mdc. Use n/a — <reason> only when the fix is purely configurational (env var, web-server header) and is described in the Recommended Fix narrative.

These fields exist so @skills/process-code-review/SKILL.md can turn each finding into a regression test and apply the fix without re-deriving the attack vector. Medium and Low findings may omit them when no behavior change is implied.

Output format

Use the template defined in templates/audit-report.md.