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