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. Use when this capability is needed.
metadata	{"author":"edwrld"}

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

---

Converted and distributed by TomeVault — claim your Tome and manage your conversions.