Skip to content

Testing workflow

Build an attack surface inventory for security testing

Map application routes, identities, data flows, integrations, and exposed assets into an owner-verified inventory with explicit assessment status.

By BugSnaps · Updated

Direct answer

An attack surface inventory maps the places where data or commands enter and leave a system, the valuable resources they reach, and the controls around them. Combine owner-provided architecture with observed application behavior, then track what has actually been assessed.

Map functions and boundaries

Include browser routes, API operations, uploads, exports, administrative interfaces, and integrations. Associate each with its owner, environment, user roles, and data sensitivity. Discovery is useful for locating assessment work; an exposed route is not automatically a vulnerability.

Reference: OWASP Attack Surface Analysis Cheat Sheet.

Walk real application journeys

A crawl can miss features that require sign-in, an existing record, or a completed workflow step. Walk through owned test-account journeys and compare the observed requests with the route inventory. Follow a created record through list, detail, export, and deletion paths.

  • Use the owner's API specification and architecture diagrams.
  • Include background jobs and generated download resources.
  • Mark unreachable and credential-dependent routes explicitly.

Prioritize meaningful changes

A new upload processor creates a different boundary from another static page. Add a change note describing the new data path and controls it needs. This helps a release assessment focus on the risk introduced rather than repeating every old check without context.

  • Flag new privileged roles and new third-party integrations.
  • Identify public assets that may contain internal configuration.
  • Review obsolete APIs and forgotten deployment environments.

Reference: OWASP Attack Surface Analysis Cheat Sheet.

Keep assessment status separate from discovery

For each relevant boundary, record assessed, excluded, unavailable, or pending, with a date and reason. A route count measures inventory size, not security assurance. Use that ledger to request missing fixtures and plan targeted follow-up after the release.

Assessment limits

An inventory can be incomplete because of missing roles, undisclosed services, inaccessible environments, or runtime conditions. Domain discovery cannot establish ownership or authorization. The inventory supports testing but does not itself validate vulnerabilities.

Frequently asked questions

Does discovering an endpoint mean it was tested?

No. Discovery records its presence. Assessment needs relevant requests, roles, controls, and results, or a visible reason the check was unavailable.

Is the attack surface only public URLs?

No. It also includes inputs, outputs, protected data paths, roles, and integrations within the agreed system boundary. Public URLs are one useful inventory layer.

How should an inventory change after a release?

Record added and removed data paths, roles, integrations, and controls. Use the change to decide which assessments and regression cases need updating.

Primary sources and further reading

These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.

Apply the guide to your own application.

Start with an authorized target, known test data, and a clear scope. Use the report's evidence and coverage limits to decide which checks need further review.

Open MyPentest