CWE-1125 describes a product whose attack surface, measured quantitatively, exceeds a desirable maximum. MITRE files it under excessive code complexity (CWE-1120) and in the complexity issues category.
MITRE's extended description defines the idea. An attack surface measure typically reflects the number of input points and output points that an untrusted party can use. A larger surface gives more places to attack and more opportunities for developers to introduce weaknesses. MITRE adds that the measure can also reflect other quality aspects: a product with many inputs and outputs may need many tests to improve code coverage.
MITRE treats the entry as a quality issue with no direct security implications and prohibits using it to map real vulnerabilities. It is still the most practical idea in this group, because it is the one you can act on directly.
How it happens
Surface grows by addition. An endpoint is added for one customer and never removed. A debug port stays open. A feature ships enabled by default. A file format gains a parser for a rarely used variant. Each addition is small, and removal always seems riskier than leaving it.
What an attacker gains
MITRE lists the consequence scope as other, with the impact varying by context. There is no single outcome, because the surface itself is not a flaw. It is the number of doors. Each extra door is another place where validation, authentication or parsing can go wrong, and another thing you must test and patch.
How to find it
The record lists no detection methods. Build an inventory and count.
- List every network listener, API route, file type parsed, message queue consumed, command line option and environment variable read.
- Mark which are reachable by an untrusted party.
- Note which are enabled by default and which are actually used.
- Compare the list to what product owners say the system needs.
A dynamic scan of a running application, and an API scan against a specification, are useful ways to discover endpoints that no one remembered to list.
How to fix it
The record has no formal mitigations. These are common ways to reduce surface.
- Remove what is unused. Retire endpoints, features and parsers nobody needs.
- Disable by default. Make optional features opt in.
- Narrow exposure. Move internal functions off public interfaces, and restrict network reach.
- Consolidate entry points. Fewer, well-tested input paths beat many ad hoc ones.
- Keep the inventory current. Review it at each release so growth is a decision, not an accident.
Try it yourself
A web scan is one way to see the surface from the outside. This demo shows how a dynamic scan discovers what a running application exposes.
Click through it at your own pace, or open it full screen.
Quick check
What does an attack surface measure typically count?
The input points and output points that an untrusted party can use, according to MITRE.
Is a large attack surface itself a vulnerability?
No. It is the number of places a vulnerability could exist. Reducing it lowers the chance and the maintenance load.
