## Authorization Bypass (Critical)

### Trigger Signals

Start this detection when the following code characteristics appear:
- Write operations in route handlers (POST/PUT/DELETE)
- Operation parameters contain user-controllable resource IDs (`userId`, `orderId`, `id` from path/query parameters)
- Functions containing sensitive operation keywords such as delete, transfer, approve, export

### Judgment Process

1. **Locate sensitive operation entry points**: `Read` identifies route definitions in changed code (`router.post/put/delete`, `@PostMapping`, etc.), marking write operation handlers
2. **Check authorization chain**: `Read` traces the middleware chain upward from route definitions, confirming whether authorization middleware is included (`requireAuth`, `checkPermission`, `@RequireRole`)
3. **Check internal function isolation**: For authorization-protected functions, `find_references` tracks all callers:
   - Whether there is a path that bypasses route middleware for direct calls (e.g., internal service methods called directly by other entry points)
   - Whether the bypassed path lacks independent authorization checks
4. **Check resource ownership verification**: For endpoints whose operation parameters contain resource IDs, `Read` confirms whether the current user's ownership of the resource is verified (not just verifying resource existence)

### Evidence Construction

After confirming a defect, the output must include:
- Sensitive operation entry point (route definition, with file:line number)
- Authorization chain analysis (whether middleware chain covers, where it breaks)
- Bypass path (if present, list the call paths that bypass authorization)
- Business impact (consequences of unauthorized operations: data leakage, malicious modification, privilege escalation)

### Exclusions

- Internal service-to-service calls (already have inter-service auth mechanisms like mTLS, JWT)
- Admin-only endpoints (already protected by admin middleware)
- Public read-only data endpoints
