An attack surface is the sum of all the points where an attacker could get into a system and where data could get out, plus the code and controls guarding those points. You reduce it by finding the entry points, removing the ones you do not need, and tightly controlling the rest.
How does OWASP define it?
The OWASP Attack Surface Analysis Cheat Sheet defines an application's attack surface as two things: all the paths for data and commands into and out of the application, together with the code that protects those paths (authentication, authorization, logging, validation and encoding), and all the valuable data in the application, including secrets, keys, intellectual property, business data and personal data, with the code that protects it.
The cheat sheet is explicit about scope. It focuses on protecting an application from external attack. It does not cover attacks on users or operators, such as malware injection or social engineering, and gives less attention to insider threats. So treat "attack surface" as a family: the application surface, the infrastructure surface under it, and the human surface around it.
What are the types?
A practical grouping:
- Application: forms, APIs, file uploads, headers and cookies, admin interfaces, webhooks.
- Network and host: open ports, exposed services, remote access. NIST SP 800-190 says every host operating system has an attack surface, the collection of all ways attackers can try to access and exploit it, and that any network-accessible service adds an entry point.
- Software supply chain: third-party libraries, build tools and plugins you did not write but run.
- Identity: accounts, tokens, keys and service credentials. Anything that can authenticate is a way in.
- Human: staff targeted by phishing or phone pretexts.
- Physical: sites, devices and hardware ports.
How do you map it?
OWASP's method is deliberately lightweight. Spend a few hours reviewing design and architecture documents from an attacker's perspective and read the code to list points of entry and exit: forms and fields, headers and cookies, APIs, files, databases, other local storage, messages and runtime arguments. The total can run into the thousands, so group them by type: login and authentication entry points, admin interfaces, search functions, data entry forms, business workflows, transactional APIs, operational command and monitoring interfaces, and interfaces to other systems. Then count each type, pick sample cases from each and focus the review there.
The cheat sheet gives two extremes to watch: unauthenticated anonymous users and highly privileged administrators. You can also scan the application with a dynamic testing tool to crawl what is reachable, then walk through main use cases such as sign-up, login and ordering to fill gaps.
For microservice and cloud-native applications, OWASP says to prioritize components reachable from an attack source, such as internet traffic, even when they sit behind proxies, load balancers and ingress controllers and auto-scale.
What deserves attention first?
OWASP highlights remote entry points and especially anonymous public access: network-facing code, web forms, files from outside the network, backward-compatible interfaces with old protocols and libraries, custom APIs that are likely to contain design mistakes, and security code covering cryptography, authentication, authorization and sessions.
Constructed example: a small SaaS product counts 140 endpoints. Sorted by type, 90 are ordinary CRUD calls behind authentication, 30 are admin routes, 12 are public, and 8 are legacy endpoints kept for one old customer. The 8 legacy routes, which use an old authentication scheme, become the first review target even though they are the fewest.
How do you reduce it?
- Remove. Delete unused endpoints, features, accounts, packages and open ports. What does not exist cannot be attacked.
- Restrict. Put admin interfaces on private networks, require stronger authentication, and limit who can reach what. Deny by default and allow by exception.
- Shrink dependencies. Fewer and better-maintained libraries mean fewer inherited flaws.
- Minimize data. Data you do not hold cannot leak.
- Watch for change. OWASP says changes to the attack surface should trigger threat assessment. Make a new public endpoint a review event.
How to check or apply this
- Draw the system and mark every entry and exit point.
- Count entry points by type and keep the count in the repository.
- Review the public, anonymous and legacy ones first.
- Delete anything unused, with owners signing off.
- Compare the count at each release and flag jumps.
- Feed new entry points into threat modeling.
- Include dependencies, build tooling and identities in the inventory, not just code.
Quick check
Is a smaller attack surface always more secure?
Not automatically, since the remaining parts still need protection. But fewer entry points means less to defend, test and patch, so it is almost always a good first move.
Does attack surface include people?
In practice yes, since phishing and pretexting are ways in. OWASP's application cheat sheet scopes them out, so treat them in a separate review.
Sources
Last reviewed: 18 October 2026.
