## Access Control Defects (Critical)

### Trigger Signals

- Object properties directly mapped from request parameters to model (`Object.assign(model, req.body)`, `model.update(req.body)`)
- API endpoints operating on resources without verifying current user's ownership of the resource
- Routes/endpoints without role checks (admin endpoints accessible by regular users)
- Batch operation endpoints (delete multiple, update multiple) without per-item permission check

### Judgment Process

1. **Check mass assignment**: `Read` confirms the mapping method from request parameters to model:
   - `Object.assign(user, req.body)` → user can pass in sensitive fields like `role: 'admin'`
   - `model.update(req.body)` → same as above
   - Should use whitelist fields (only allowing safe fields like `name`/`email`)
2. **Check resource-level authorization (IDOR)**: `find_references` tracks resource operation functions, confirming whether current user's ownership of the resource is verified:
   - Whether query filters on `userId === currentUser.id`
   - Whether resource ID comes from user-controllable parameters (path parameters, query parameters)
   - Whether batch operations check permissions per item (rather than checking once and operating on all)
3. **Check roles/permissions**: `Grep` searches for route definitions, `Read` confirms whether sensitive endpoints (admin operations, delete, export) have role middleware:
   - Whether relying solely on frontend hiding (frontend hiding buttons != backend restriction)
   - Whether role check is in middleware (rather than manually checking in each handler)

### Evidence Construction

After confirming a defect, the output must include:
- Defect location (mass assignment/IDOR/missing role check location, with file:line number)
- Attack vector (modify request parameters for privilege escalation, tamper ID to access others' data)
- Exploitation scenario (`{ "role": "admin" }`, modify `/api/users/123` to `/api/users/456`)
- Business impact (privilege escalation, data leakage, unauthorized operations)

### Exclusions

- Already using whitelist field filtering (`pick(req.body, ['name', 'email'])`)
- Already has resource ownership verification (query conditions include `userId`)
- Already has role middleware protecting sensitive endpoints
- Note: Business logic level permission bypass is covered by logical-defects/authorization-bypass.md

### Relationship with Logical Defects

This file focuses on **attack vectors** (how to bypass controls by tampering request parameters), while logical-defects/authorization-bypass.md focuses on **business semantics** (whether permission checks were missed). They are complementary; it is recommended to detect both simultaneously.
