Application Attack-Surface Modeling

Purpose

Reconnaissance produces a list of routes and endpoints. That list is not yet an application. This skill turns observed runtime behavior into a structured model - who exists, what exists, what flows exist, what states exist, and where the boundaries are - and converts the model into testable hypotheses for the ledger. Load this skill when the endpoint inventory feels like "many URLs, little meaning", or before starting systematic application-level testing.

Entry Conditions

• Reconnaissance has produced a concrete endpoint/page inventory (including client-side routes from discover_client_routes)
• Login flows, forms, and API surfaces are mapped at a surface level
• You need to decide WHICH application-level attacks to run and in what order

Application Model: What to Capture

Work through these dimensions in order; each one generates hypothesis material:

1. Roles and privilege states

Enumerate the distinct identities the application recognizes, not just the accounts you hold:

Anonymous
  -> signup -> User
  -> email verification -> Verified User
  -> subscription -> Pro User
  -> invite member -> Organization Admin
  -> platform grant -> Moderator / Support / Owner

Signals for role discovery: signup/register forms, pricing tiers, invite flows, admin links, role names in API responses, menu differences between your test accounts, X-Tenant-ID / X-Org-ID headers, role claims in decoded cookies/tokens.

2. Resources and object types

Every ID-bearing endpoint names a resource type: users, orders, documents, invoices, tickets, messages, api_keys, webhooks, exports, workspaces, tenants. For each: how are IDs generated (sequential, UUID, slug)? Who can create/read/update/delete? Are they tenant-scoped or global? Sequential IDs across tenants are an enumeration lead; UUIDs are not.

3. Workflows and state transitions

Every multi-step flow is a state machine. For each transition capture: