# Application Attack Surface Modeling

Build a working model of the application as a system - roles, resources, workflows...

- Repository: https://github.com/xalgorix/xalgorix (1285 stars)
- Category: Engineering
- License: Apache-2.0
- Last updated: 2026-10-30
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add xalgorix/xalgorix --skill application-attack-surface-modeling -g -a claude-code -y`
Codex: `npx skills add xalgorix/xalgorix --skill application-attack-surface-modeling -g -a codex -y`
Cursor: `npx skills add xalgorix/xalgorix --skill application-attack-surface-modeling -g -a cursor -y`
Gemini CLI: `npx skills add xalgorix/xalgorix --skill application-attack-surface-modeling -g -a gemini-cli -y`

## Description

Build a working model of the application as a system - roles, resources, workflows, state transitions, trust and tenant boundaries - from black-box behavior, and turn that model into prioritized hypotheses. The foundation skill that converts a recon endpoint list into application-level reasoning.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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:

```text
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:

The rest: https://github.com/xalgorix/xalgorix/blob/HEAD/internal/tools/skills/data/application-security/application-attack-surface-modeling/SKILL.md