privilege-escalation

What this skill does

# Elevation of Privilege Analysis

Analyze source code for privilege escalation threats where attackers can gain unauthorized capabilities or access. Maps to **STRIDE E** -- violations of the **Authorization** security property.

## Supported Flags

Read [`../../shared/schemas/flags.md`](../../shared/schemas/flags.md) for the full flag specification. This skill supports all cross-cutting flags including `--scope`, `--depth`, `--severity`, `--format`, `--fix`, `--quiet`, and `--explain`.

## Framework Context

Read [`../../shared/frameworks/stride.md`](../../shared/frameworks/stride.md), specifically the **E - Elevation of Privilege** section, for the threat model backing this analysis. Key concerns: broken access control (IDOR), missing function-level access control, JWT manipulation, role confusion, privilege escalation.

## Workflow

### 1. Determine Scope

Parse flags and resolve the target file list per the flags spec. Filter to files implementing authorization:

- Route handlers with role checks and permission guards
- Authorization middleware and policy enforcement points
- RBAC/ABAC implementations and permission models
- Admin endpoints and administrative interfaces
- User management (create, update roles, delete accounts)
- Object ownership checks and tenant isolation logic
- API controllers and GraphQL resolvers with access control
- Infrastructure-as-code defining IAM roles and security groups

### 2. Analyze for Privilege Escalation Threats

For each in-scope file, apply the Analysis Checklist below. At `--depth standard`, examine authorization logic in each file. At `--depth deep`, map the full authorization architecture: who can access what, where checks are enforced, where gaps exist between routes, and whether authorization is consistently applied at every layer.

### 3. Report Findings

Output findings per [`../../shared/schemas/findings.md`](../../shared/schemas/findings.md) using the `PRIV` ID prefix (e.g., `PRIV-001`). Set `references.stride` to `"E"` on every finding.

## Analysis Checklist

Work through these questions against the scoped code. Each "yes" may produce a finding.

1. **Missing function-level access control** -- Are admin or privileged endpoints accessible without role verification? Compare route definitions: if some routes check `isAdmin`, `requireRole('admin')`, or `@permission_required`, identify sibling routes that should but do not have equivalent guards. Map all endpoints and flag gaps in the authorization layer.
2. **Insecure direct object references (IDOR)** -- Do endpoints use user-supplied IDs to fetch resources without verifying ownership? Look for `findById(req.params.id)`, `getRecord(id)` where the result is not checked against the requesting user's permissions or tenant. Test: can user A access user B's resources by changing the ID?
3. **JWT claim manipulation** -- Are JWT role or permission claims trusted without server-side verification? Check if role-based decisions use claims from the token payload without cross-referencing a server-side authority (database, LDAP). Look for `jwt.decode` without verify, or role checks solely from token claims.
4. **Client-side authorization** -- Are access control decisions made only in frontend code (React/Vue/Angular component guards, route guards) without corresponding server-side enforcement on the API endpoints they call? Search for `role`, `isAdmin`, `canAccess` in frontend code and verify equivalent checks exist server-side.
5. **Mass assignment to role fields** -- Can users set their own role, `isAdmin`, `permissions`, or `group` fields through API requests? Look for ORM `.create(req.body)` or `.update(req.body)` without excluding privilege-related fields. Check for `attr_accessible`, `fillable`, `$guarded`, or DTO validation that strips role fields.
6. **Default admin accounts** -- Are there hardcoded admin users created in seed scripts, migrations, or initialization code with well-known credentials? Look for `role: 'admin'` combined with `password:` in seed data. Check if these are gated behind environment checks (`if NODE_ENV === 'development'`).
7. **Horizontal privilege escalation** -- Can users access other users' resources by manipulating IDs? Check if resource queries include ownership filters (`WHERE user_id = ?` or `WHERE org_id = ?`) or if they rely solely on the resource ID from the request. Multi-tenant applications must enforce tenant isolation on every query.
8. **Trust boundary violations** -- Are internal-only services or endpoints accessible from external networks? Look for admin APIs without network-level restrictions, internal microservice calls that accept external requests, or debug/management ports exposed without authentication.
9. **Broken role hierarchy** -- Is the role hierarchy enforced consistently? Check if `editor` can perform `admin` actions, or if role inheritance has gaps. Look for permission checks using string comparison (`if role === 'admin'`) instead of hierarchical evaluation that accounts for role inheritance.
10. **Missing deny-by-default** -- Does the authorization system default to allow when no explicit rule matches? Check middleware ordering: is there a catch-all deny at the end, or do unmatched routes pass through without authorization? Look for `next()` called unconditionally in auth middleware.
11. **Path parameter manipulation** -- Can URL path parameters be manipulated to bypass route-level authorization? For example, accessing `/api/admin/../user/settings` to bypass admin-only middleware, or using URL encoding tricks to evade path-based access rules.
12. **Scope/permission creep in tokens** -- Are OAuth scopes or API key permissions overly broad? Check if tokens are issued with `scope: *`, full permissions, or if fine-grained scopes are available but not enforced. Look for scope validation at the endpoint level, not just at token issuance.

## Pragmatism Notes

- Single-user applications or personal tools may not have authorization at all, and that is fine. Only flag missing authz when the application clearly has multiple user roles or multi-tenancy.
- IDOR findings require understanding the data model. Not every `findById(req.params.id)` is an IDOR -- some resources are intentionally public (e.g., blog posts, product listings). Focus on resources that contain user-private data.
- Client-side route guards are expected for UX (hiding admin buttons from regular users) but are not security controls. Only flag when the corresponding server-side check is missing.
- Mass assignment protections vary by framework. Before reporting, check if the framework has built-in protection (Rails strong params, Django ModelForm, NestJS DTOs with class-validator). Flag only when protection is absent or misconfigured.
- Role hierarchies are application-specific. A flat role model (`admin` / `user`) is not a finding. Flag only when the code shows evidence of an intended hierarchy that is inconsistently enforced.

## What to Look For

Concrete code patterns and grep heuristics to surface privilege escalation risks:

- **Unprotected admin routes**: Routes containing `/admin`, `/manage`, `/internal`, `/dashboard`, `/settings` without auth middleware. Compare middleware chains between admin and public routes. Grep: `(admin|manage|internal|dashboard)` in route definitions.
- **Direct ID lookups without ownership**: `Model.findById(req.params.id)` or `db.query("SELECT ... WHERE id = $1", [req.params.id])` without a `user_id` or `org_id` filter joined to the session user. Grep: `findById\s*\(\s*req\.(params|query)|WHERE id\s*=` without ownership clause.
- **Role from client**: `req.body.role`, `request.data['is_admin']`, `params[:role]` used in user creation or update without stripping. Also `req.user.role` derived solely from JWT without server-side lookup. Grep: `req\.(body|query|params)\.(role|isAdmin|is_admin|permissions|group)`.
- **Missing middleware on routes**: Routes registered after auth middleware is applied vs. routes regi