Thorough, adversarial security review of API endpoints, UI flows that call those endpoints, and any database-interacting code. Use when the user asks for a security review, permission/authorization audit, red-team style assessment, or vulnerability analysis. Assume access to source code and a running system; perform threat modeling and check current vulnerabilities relevant to the stack.
apm install @edwrld/security-review---
name: security-review
description: Thorough, adversarial security review of API endpoints, UI flows that call those endpoints, and any database-interacting code. Use when the user asks for a security review, permission/authorization audit, red-team style assessment, or vulnerability analysis. Assume access to source code and a running system; perform threat modeling and check current vulnerabilities relevant to the stack.
---
# Security Review
## Overview
Perform a red-team style review of API endpoints, the UI flows that call them, permission boundaries, and database interactions. Produce prioritized findings with concrete exploit paths and fixes.
## Workflow Decision Tree
1. **Confirm scope**
- If the user names specific endpoints/features, proceed. Otherwise ask for the feature list, roles, environments, and access level.
- If the system is running and reachable, do both static review and dynamic tests. If not, do static-only and flag verification gaps.
2. **Inventory & mapping (static first)**
- Enumerate API endpoints, handlers, auth middleware, and data access points.
- Map UI flows to endpoints and identify where permissions should be enforced server-side.
- Identify database tables and relationships accessed by the feature; use MCP DB tools to understand schema and permission boundaries.
3. **Threat model the feature**
- Use STRIDE for endpoints and data flows; use LINDDUN for privacy risks; align with OWASP ASVS / OWASP API Security Top 10 categories.
- Identify trust boundaries, entry points, assets, and abuse cases.
4. **Deep-dive reviews**
- Authorization and permission gaps (vertical + horizontal)
- Input validation and injection exposure
- Session, token, and credential handling
- Data access and tenancy isolation
- Abuse protections (rate limits, replay, enumeration, business logic)
5. **Dynamic testing (when running system is available)**
- Attempt privilege escalation, IDOR, forced browsing, parameter tampering, and workflow bypasses.
- Validate server-side enforcement vs. client-side checks.
6. **Vulnerability intelligence**
- Identify framework/runtime versions and key dependencies.
- Use WebSearch + WebFetch to confirm the latest vulnerabilities (CVEs/advisories) relevant to those components; cite sources.
7. **Deliverable**
- Provide a structured report with findings, evidence, exploit paths, fixes, and verification steps.
## Required Tools and Data Sources
- **Codebase search**: use `rg` to find endpoints, auth checks, role gates, and DB access.
- **Running system**: use available API/UI access to validate real-world enforcement.
- **Database schema**: use MCP `dbhub` and `dbhub-crm` to understand tables, relationships, and likely access boundaries.
- **Vulnerability intel**: use WebSearch/WebFetch to verify current, authoritative advisories.
## Core Review Steps
### 1) Scope and Inventory
- List endpoints, handlers, and related UI flows.
- Identify roles/permissions expected for each operation.
- Enumerate data assets involved (PII, financial, operational data) and identify where they live in DB.
### 2) Authorization & Permission Audit
- Confirm **server-side** authorization for every sensitive action.
- Test for IDOR and horizontal access (e.g., `customer_id`, `account_id` swaps).
- Test vertical escalation (low-priv user accessing admin endpoints).
- Verify permission checks near data access (before queries, not just in UI).
### 3) Data Access and DB Boundaries
- Trace requests to DB queries and ensure least-privilege access.
- Look for direct SQL execution, weak row filtering, or missing tenant scoping.
- Use MCP schemas to identify related tables that should be constrained by permissions.
### 4) Input Validation & Injection Surface
- Check for SQLi, command injection, SSRF, path traversal, and deserialization issues.
- Validate JSON schema / parameter validation at boundaries.
- Verify output encoding for any reflected data.
### 5) Authn/Session/Secrets
- Review token handling, session fixation, CSRF exposure for state-changing operations.
- Validate logout/invalidation and token rotation.
- Scan for hardcoded secrets, weak key storage, or overly broad API keys.
### 6) Abuse & Business Logic
- Test rate limits, brute-force protections, and enumeration controls.
- Attempt workflow bypasses and state manipulation.
- Check audit logging for sensitive changes and access.
## Reporting Guidance
- Provide a ranked list of findings (Critical/High/Medium/Low/Info).
- Each finding should include:
- **Summary**
- **Evidence** (code path, endpoint, or reproduction steps)
- **Impact**
- **Exploit path**
- **Fix recommendation**
- **Verification steps / tests**
- Call out assumptions and any untested areas.
## References
- **Threat modeling**: See `references/threat-modeling.md`
- **Security checklist**: See `references/security-checklist.md`
- **Report template**: See `references/report-template.md`