CWE stands for Common Weakness Enumeration. It is a community-developed knowledge base of recurring weaknesses in software and hardware. Each type receives an unambiguous identifier such as CWE-79 for cross-site scripting or CWE-89 for SQL injection. Developers, testers, tool vendors and security owners can use this common language to describe the same class of mistake and compare findings across different products.
What is a weakness?
A weakness is a condition in architecture, design, code or implementation that may contribute to an exploitable vulnerability under suitable circumstances. Examples include missing authorization checks, unsafe memory access, hard-coded credentials or passing user input to an interpreter without proper neutralization. A weakness therefore describes the type or cause of a mistake, not automatically a specific vulnerable product release.
Several concrete vulnerabilities may share the same cause. An SQL injection in an online shop and one in an administrative application can both map to CWE-89 even though their source code, vendors and impact differ. This abstraction makes recurring root causes visible and helps prevent them during development.
How is CWE structured?
CWE is not a simple flat list. Weaknesses have relationships and different levels of abstraction. An abstract entry encompasses more possible cases; a specific entry contains more detail about the cause, technology and possible mitigations.
| Level | Meaning | Example |
|---|---|---|
| Pillar | A highly abstract, top-level kind of weakness. | CWE-707: Improper Neutralization |
| Class | A technology-independent class with more precise faulty behavior. | CWE-74: Injection |
| Base | A sufficiently concrete weakness from which testing and prevention can be inferred. | CWE-79: Cross-site Scripting |
| Variant | A specific form tied to a technology, language or resource. | CWE-83: Script in HTML Attributes |
Categories, Views and Compound Elements also exist. A Category groups related entries but is not itself a weakness. A View presents the catalog for a particular purpose, such as software development, research or hardware design. Composites combine multiple weaknesses that must occur together; Chains describe a sequence in which one weakness enables another. A faulty integer calculation leading to a buffer overflow is one example of such a chain.
What information does a CWE entry contain?
- Description:
The faulty behavior that defines the weakness and distinguishes it from similar entries. - Introduction phase:
Whether it commonly arises during requirements, architecture, design, implementation or operation. - Consequences:
Possible effects on confidentiality, integrity, availability or access control. - Detection:
Code analysis, manual review or dynamic testing methods that may identify it. - Mitigations:
Design and implementation approaches that prevent or restrict the root cause. - Examples and references:
Demonstrative code, observed CVEs, relevant platforms and related attack patterns. - Relationships:
Parents, children, possible chains, Views and mappings to external taxonomies.
Not every entry contains the same depth of information. Nevertheless, the detailed CWE page is often a useful starting point for connecting a finding to its root cause, possible consequences and suitable prevention measures.
How do CWE, CVE, CVSS and CAPEC differ?
| System | Describes | Example question |
|---|---|---|
| CWE | A general type of weakness or root cause. | Which kind of development or design mistake is present? |
| CVE | A publicly known concrete vulnerability in a product or component. | Which product release is affected by which disclosed vulnerability? |
| CVSS | Technical characteristics and severity of a particular vulnerability. | How severe is the vulnerability under the described conditions? |
| CAPEC | Attack patterns and common attacker behavior. | How might an attacker exploit an existing weakness? |
Consider a simplified example: an application inserts user input into an SQL query without proper handling. The root cause can be classified as CWE-89. If this flaw is disclosed in a particular product version, it may receive a CVE identifier. A CVSS vector describes the technical exploitability and impact of that concrete vulnerability. The actual business risk additionally depends on exposure, the affected function, data and existing safeguards.
How is the correct CWE selected?
- Separate observation from cause: Do not stop at the visible impact; determine the mistake that made it possible.
- Use a suitable View: Navigate through the Development or Research View depending on the purpose.
- Map as specifically as evidence permits: Prefer a Base or Variant without claiming details that were not established.
- Compare related entries: Check descriptions, relationships, distinctions and examples on the CWE site.
- Explain the mapping: State which observed behavior supports the chosen identifier.
An abstract label such as the general Injection class is less actionable than a supported mapping to SQL, LDAP or command injection. Conversely, a specific Variant is incorrect when the required technology or cause was not verified. Categories and Views should not be mapped as the root cause of an individual finding.
How is CWE used in practice?
Software development
Teams can analyze recurring CWEs in findings and turn them into coding guidelines, shared libraries, architecture requirements and focused training. If CWE-862 “Missing Authorization” recurs, closing individual tickets is not enough. Central authorization mechanisms, clear ownership and automated negative permission tests address the underlying pattern more effectively.
Penetration testing and code analysis
A penetration test can attach CWE IDs to findings, giving clients a standardized reference and allowing findings from several reports to be grouped. SAST, DAST and SCA tools also use CWE, but their mappings require review: an automated result proves neither the root cause nor practical exploitability by itself.
Metrics and procurement
CWE classifications enable trend analysis: Which mistakes recur? At which phase are they introduced? Which teams need support? Contracts and security requirements can reference relevant weaknesses. A raw count of closed CWEs is not a reliable security metric, however; severity, system context and repeated root causes have to be considered.
What is the CWE Top 25?
The CWE Top 25 ranks especially widespread and consequential software weaknesses using published CVE data. In the 2025 edition, CWE-79 cross-site scripting, CWE-89 SQL injection, CWE-352 cross-site request forgery, CWE-862 missing authorization and CWE-787 out-of-bounds write occupied the first five positions. Other highly ranked causes included path traversal, use after free, out-of-bounds read, OS command injection and code injection.
The Top 25 is useful for awareness and prioritizing broad secure-coding measures. It is not a complete testing checklist for every application. A weakness outside the ranking may represent the greatest risk to a particular product. Technology, architecture and threat model still matter.
What are the limitations of CWE?
A CWE identifier measures neither severity nor the actual business risk of a finding. The same mistake may be critical in a public administrative interface and nearly irrelevant in an isolated test utility. Nor does the catalog guarantee one perfectly unambiguous mapping: weaknesses can overlap, occur in chains or be described at different levels of precision depending on available evidence.
CWE is primarily a shared language and knowledge base. It improves reporting, root-cause analysis and prevention, but does not replace technical verification or risk assessment. Its greatest value emerges when teams do more than collect identifiers and use recurring causes to improve the development process.
Thank you for your feedback! We will review it and optimize this content.