0x1337c0d3/attack-surface

Attack Surface Mapping

Discover and inventory every entry point where external data enters the application. Produces a ranked catalog of all routes, APIs, input handlers, and external interfaces organized by exposure level and trust boundary.

Most useful as a pre-scan step before running /sentinel — identifies where to focus scanning effort and surfaces unauthenticated endpoints that are high risk.

Usage

/sentinel:attack-surface                  # Full surface map (default: full scope)
/sentinel:attack-surface --depth quick    # Route extraction only (fast)
/sentinel:attack-surface --depth deep     # Trace entry points to internal sinks
/sentinel:attack-surface --format json    # Machine-readable inventory

Workflow

Step 1 — Detect Framework and Language

Identify the application framework to determine route registration patterns:

| Framework | Route Pattern | |-----------|--------------| | Express/Koa/Fastify | app.get(), router.post(), fastify.route() | | Django | urlpatterns, path(), re_path(), @api_view | | Flask | @app.route(), @blueprint.route() | | Spring | @GetMapping, @PostMapping, @RequestMapping | | Rails | routes.rb, resources :, get '/' | | Next.js/Nuxt | pages/ and app/ directory conventions, route.ts | | ASP.NET | [HttpGet], [Route], MapGet(), MapPost() | | Go net/http | http.HandleFunc(), mux.Handle(), gorilla/chi patterns | | FastAPI | @app.get(), @router.post() | | gRPC | .proto service definitions | | GraphQL | Schema definitions, resolver registrations |

Use Grep to find these patterns directly in the source tree.

Step 2 — Extract Entry Points

For each framework detected, systematically extract all entry points:

1. HTTP Routes: Method, path, handler function, middleware chain
2. API Endpoints: REST, GraphQL queries/mutations, gRPC services
3. Form Handlers: HTML form action targets, multipart upload handlers
4. File Upload Endpoints: Endpoints accepting file data, storage destinations
5. WebSocket Handlers: Connection endpoints, message handlers
6. CLI Arguments: Argument parsers (argparse, commander, cobra)
7. Message Queue Consumers: Kafka/RabbitMQ/SQS message handlers
8. Webhook Receivers: Endpoints accepting callbacks from external services
9. Scheduled Tasks: Cron jobs that process external data

Step 3 — Classify Each Entry Point

For every discovered entry point, determine:

| Attribute | Values | |-----------|--------| | Authentication | None, API key, session, JWT, OAuth, mTLS, unknown | | Authorization | None, role-based, attribute-based, unknown | | Input types | Query params, path params, headers, body (JSON/XML/form), files, cookies | | Validation | Present (with details) or absent | | Rate Limiting | Present or absent | | Network exposure | Internet-facing, internal network, localhost only |

Step 4 — Rank by Exposure

| Level | Criteria | |-------|----------| | CRITICAL | Internet-facing, no authentication, accepts user input, interacts with sensitive data or system resources | | HIGH | Internet-facing with authentication but handling sensitive data, or unauthenticated with limited input validation | | MEDIUM | Authenticated endpoints with proper validation, or internal endpoints with no authentication | | LOW | Internal endpoints with authentication, limited input surface, or read-only operations on non-sensitive data |

At --depth deep, trace each HIGH/CRITICAL entry point inward to identify what sinks they reach (databases, file system, external services, system commands).

Step 5 — Identify Shadow Endpoints

Look for:

• Debug/admin routes not behind auth middleware (/debug, /admin, /metrics, /health exposing internals)
• Deprecated API versions still routed (/api/v1/ when /api/v2/ is current)
• Swagger UI / OpenAPI browser exposed without authentication
• Endpoints in test configuration that may be active in production
• Routes registered dynamically that don't appear in static route lists

Step 6 — Produce Inventory Report

## Attack Surface Inventory

### Summary
- Total entry points: N
- Internet-facing: N (N unauthenticated)
- Internal: N
- Exposure: N CRITICAL, N HIGH, N MEDIUM, N LOW

### Entry Points by Exposure

| # | Method | Path | Auth | Input Types | Validation | Rate Limit | Exposure |
|---|--------|------|------|-------------|------------|------------|----------|
| 1 | POST | /api/v1/users | None | JSON body | None | No | CRITICAL |
| 2 | GET | /api/v1/users/:id | JWT | Path param | Partial | Yes | MEDIUM |

### Shadow Endpoints
[Undocumented or debug endpoints discovered]

### Trust Boundary Map (--depth deep)
[Entry points grouped by trust boundary — internet vs internal vs admin]

### Findings
[Missing security controls on HIGH/CRITICAL entry points]

Step 7 — Produce Findings for Missing Controls

When entry points have clearly missing security controls, emit findings:

[SURF-XXX] Title
Severity: CRITICAL/HIGH/MEDIUM/LOW | CWE: CWE-306 (Missing Auth) or CWE-16 (Config)
Location: file:line (route definition)

Entry point: [METHOD] [path]
Issue: [Missing authentication / no rate limit / no input validation]

Risk: [Who can reach this and what they can do]

Fix: [Add auth middleware / rate limiter / input size limit]

Finding ID prefix: SURF

Pragmatism Notes

• Health check endpoints (/health, /ready) without auth are normal in container orchestration. Only flag if they expose sensitive internal state.
• Internal APIs behind a service mesh or VPN still warrant inventory but at lower exposure level.
• CLI tools that only run locally have minimal attack surface unless they parse untrusted files.

Sentinel Integration

Attack surface mapping is the ideal pre-scan step before /sentinel:

• Identifies unauthenticated endpoints to prioritize in SAST scan
• Gives Sentinel's run-sast.sh a focused target list
• Surfaces shadow/debug endpoints gitleaks won't find
• SURF findings map to OWASP A01 (Broken Access Control) and A05 (Misconfiguration)
• Combine with /sentinel:api for deep analysis of HIGH/CRITICAL endpoints

---

Report Format

Format your final output following the standard Sentinel report structure defined in ${CLAUDE_SKILL_DIR}/../../templates/report.md. Use your skill's domain-specific finding IDs (e.g. STRIDE-SPOOF-001, RT-SK-001, API-001) in the Finding ID column. Include the Security Scorecard and Findings sections as a minimum. Omit the Cross-Validation Summary section if you ran only AI analysis (no tool comparison).