Attack Surface
Attack surface is the sum of entry points an attacker can reach, including APIs, uploads, dependencies, admin tools, and cloud identities, not just public URLs.
Definition
Attack surface is the collection of all points where an unauthorized actor could interact with a system, encompassing network services, APIs, user interfaces, file uploads, third-party components, credentials, and operational tooling.
Context and scope
Use it when prioritizing security work, reviewing a new feature, or reducing exposure after an incident, because every reachable component must be defended or removed.
Common misconceptions
- Attack surface means public endpoints only; internal admin panels and CI systems count too
- Adding a WAF reduces the surface; it filters traffic but leaves the reachable code in place
- Unused features are harmless; disabled routes can remain reachable through alternate paths
Anti-patterns
- Shipping debug and admin endpoints to production behind an easily guessed path
- Granting broad cloud roles that create identity-based entry points
- Tracking only documented APIs while shadow endpoints accumulate
Related concepts
Related examples
Authoritative source
https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html
More than open ports
Traditional inventories count listening services. Modern attack surface also includes HTTP routes, GraphQL resolvers, file uploads, webhook receivers, third-party scripts, package dependencies, CI runners, and cloud identities. Anything that accepts input or holds privilege is part of the surface, whether or not it is documented.
How it works
Start with an inventory: routes from the framework, public cloud resources, DNS records, OAuth clients, CI workflows, and dependency trees. Classify each entry point by who can reach it, what it can do, and what it trusts. Then reduce: remove unused routes, close unused ports, scope identities, and turn off features that are not needed.
Monitoring complements the inventory. Access logs, gateway telemetry, and cloud asset inventories reveal shadow endpoints and drift. A route that appears only after a feature flag flips is still part of the surface.
When to use it
Review attack surface before launching a feature, after an acquisition, and during incident response. It is especially useful when a team believes it has a small footprint; the inventory usually shows otherwise. Pair it with threat modeling to ask not only what is exposed but how it can be abused.
Trade-offs
Reducing surface can remove functionality customers rely on. Aggressive inventorying creates maintenance work and false positives. A WAF or API gateway centralizes policy but can create the illusion that exposed code is safe. Internal services still need authentication because the network perimeter is not a trust boundary.
Example and misconceptions
A team disables its admin UI in production but leaves the route registered and reachable through an internal load balancer. An attacker with a foothold in the network finds it and uses default credentials. The surface was never actually reduced.
The common misconception is that attack surface is a number to minimize at all costs. Some surface is the product; the goal is to know it, constrain it, and defend it deliberately.
Related concepts: Threat Modeling, Defense in Depth, and Blast Radius.