Attack surface describes every place where the behaviour or data of a system can be reached. It includes public screens, but it also includes APIs, background jobs, webhooks, file processors, administrative tools, cloud configuration, and third-party components. A route does not need to appear in the product navigation to belong to the attack surface.
Why the visible product is not the full system
A rapidly generated product can accumulate entry points feature by feature. A new upload route, callback, maintenance command, or test endpoint may remain after its original purpose changes. Authentication can protect the main interface while a secondary path applies different checks.
An audit of vibe-coded software reconstructs the exposed system from code and configuration. The review follows inputs from their entry point to the data or operation they can affect. This connects the inventory to threat modeling, which identifies the consequences that matter at each boundary.
| Surface area | What the audit inventories | Typical evidence |
|---|---|---|
| Web and API | Routes, methods, parameters | Router and schema definitions |
| Identity | Login, sessions, service accounts | Middleware and token checks |
| Data exchange | Uploads, exports, webhooks | Parsers, storage, signature checks |
| Operations | Admin tools, jobs, scripts | Privilege checks and deployment access |
| Supply chain | Packages and external services | Manifests, configuration, network calls |
Exposure and vulnerability are different
An entry point is not automatically a flaw. It becomes relevant when it is reachable and has access to something valuable. A public status endpoint may expose little. An unlisted administrative route may change customer data. The audit therefore records both reachability and effect instead of treating every route as equally risky.
Several distinct weaknesses can sit on the same surface. A database-backed search route may permit SQL injection. A page that renders submitted content may permit cross-site scripting. A file endpoint may allow path traversal. Mapping the surface provides the list of places where those checks belong.
How an audit maps the surface
The review works from the implementation rather than from a feature list:
- Enumerate entry points: List routes, events, files, jobs, commands, and integrations.
- Identify callers: Record whether each path accepts users, staff, services, or anonymous traffic.
- Trace effects: Follow reads, writes, external calls, and privileged operations.
- Locate controls: Find authentication, authorization, validation, isolation, and limits.
- Remove uncertainty: Confirm whether old, hidden, or environment-specific paths remain reachable.
What a useful surface map shows
The output ties each entry point to an owner, a trust level, the data or operation behind it, and the control that protects it. Duplicate handlers and inconsistent middleware become visible because similar paths sit beside each other.
The map is also a maintenance tool. A new feature expands the surface when it adds a route, permission, data flow, dependency, or deployment capability. The production discipline described in vibe coding versus agentic engineering requires that expansion to be understood before the feature ships.
