Font Size Change

HOMEIT SecurityMeasures for Information Security VulnerabilitiesIPA/ISEC:Vulnerabilities:CWE (Common Weakness Enumeration) Overview


IT Security

IPA/ISEC:Vulnerabilities:CWE (Common Weakness Enumeration) Overview

A list of software weakness types to provide a common language for identifying the type of vulnerability

Last updated : April 5, 2022
IT Security Center
Information-technology Promotion Agency, Japan

CWE (Common Weakness Enumeration)(*1) aims to provide a common base to identify the type of software weakness (vulnerability).

Leading the effort with support from the U.S. government, MITRE(*2) had been working on a specification since 1999 and published the first draft in March 2006. More than 40 vendors and research entities have joined hands to improve and expand the specification since then and the version 1.0 of CWE was published on September 9, 2008.

CWE gives a hierarchically structured list of weakness types to help identifying software vulnerabilities that come in a wide variety, such as SQL injection, cross-site scripting and buffer overflow. The use of CWE will enable software developers and security experts to:

  1. Have a common language to discuss software vulnerability in architecture, design and code.
  2. Use as a standard measuring rule for security tools, such as a vulnerability scanning tool, to enhance software security.
  3. Use as a common foundation to understand, mitigate and prevent vulnerability.

CWE has been adopted by NIST(*3) for NVD(*4), OWASP(*5) for Top Ten Project(*6) and other security vendors.

This overview is based on CWE Version 1.5, released by MITRE. For more information, please refer to MITRE CWE List.

1.CWE Structure

CWE organizes a wide variety of weakness types in a hierarchical structure and gives a unique identifier (CWE-ID) to each type. The weakness types at higher levels in the structure gives a more abstract and broader concept, while those at deeper level gives a more concrete concept or represent an actual CWE entity.

There are four structural classifications in CWE: View, Category, Weakness and Compound Element. Currently, 22 weakness types are classified as View, 105 as Category, 638 as Weakness and 12 as Compound Element. In total, 777 CWE entries are defined and organized in the list.


Each View entry represents a perspective with which one may use CWE and organizes weakness types from the perspective.
For example, NIST has handpicked 19 weakness types from CWE based on the vulnerabilities published on NVD and lists them on its Web site (CWE Cross Section Mapped into by NVD). The View that consists of those 19 weakness types is being given the CWE-ID of CWE-635, Weaknesses Used by NVD.
Likewise, CWE-699 is the View organized from the perspective of developers, CWE-1000 from that of researchers, CWE-658 from that of C and CWE-660 from that of Java.


Each Category entry, given a “grouping” capability, represents a collection of weakness types that share a common characteristic.
For instance, CWE-310 is a group of weakness types with cryptographic issues and CWE-355 with user interface issues.


Each Weakness entry represents an actual CWE entity and is subsequently classified using three attributes: Class, Base and Variant.
The Class attribute suggests the most abstract type of weakness of the three. CWE-362, Race Condition, is an example of this type.
The Base attribute suggests a more specific type of weakness that is independent of specific technology or resource. CWE-567, Unsynchronized Access To Shared Data, is an example of this type.
The Variant attribute suggests a specific type of weakness that is dependent of particular resource, technology or context. CWE-488, Data Leak Between Sessions, is an example of this type.

(4)Compound Element

Each Compound Element entry represents an aggregation of related weakness types with a composite nature and is subsequently classified using two attributes: Composite and Chain.
The Composite attribute suggests a case where a weakness emerges in combination of another weakness. CWE-352, Cross-Site Request Forgery, is an example of this type.
The Chain attribute suggests a case where a weakness results in another weakness. CWE-680, Integer Overflow to Buffer Overflow, is an example of this type.

2.Elements of CWE

The CWE List is organized by CWE-ID and each CWE entry is provided with various information.
To name a few, the CWE elements include Description, Likelihood of Exploit, Common Consequences, Potential Mitigations, Demonstrative Examples and Observed Example.
Users could use the CWE List as reference to identity, mitigate and prevent vulnerabilities.

3.JVN iPedia declared CWE-Compatible

JVN iPedia began to support CWE as a trial on September 10, 2008(*7). IPA had worked on a few remaining requirements to make a CWE compatibility declaration and declared it CWE-Compatible on October 3, 2008.

The official list of organizations participating in the CWE Compatibility and Effectiveness Program is available on Mitre’s CWE web site.

MyJVN began to support CWE on October 23, 2008(*8).

The four mandatory requirements – “CWE Searchability”, “CWE Output”, “CWE Documentation” and “Mapping Accuracy” – for phase 1 are fulfilled by the functions illustrated in Table 1.

Table 1. Requirement Correspondence Status
of JVN iPedia and MyJVN

Fulfillment Method


JVN iPedia,

By using the search function in JVN iPedia, the vulnerability countermeasure information database, users are able to conduct a search using CWE identifiers as the keyword.

JVN iPedia

CWE identifiers are displayed in the “References” section within each vulnerability countermeasure information pages.


CWE identifier is displayed in the “Advisory, related information” section of the detailed information window of each vulnerability countermeasure information.


JVN iPedia,

This material document will become the documentation necessary to describe and demonstrate CWE, CWE association and methods used to satisfy the compatibility requirements.


JVN iPedia,

By setting a JVN iPedia ID in the sec:identifier field of JVNDBRSS, which is used to specify the identifier of the security information, and storing the JVN ID and CWE identifier in the sec:reference field, which are used to specify the URL of the related security information, it is possible to demonstrate the correspondence of the JVN iPedia ID with the CWE identifier.


Figure 1 shows a hierarchical structure of weakness types to be used by JVN iPedia. It is based on Development View with Abstractions Highlighted, which is a graph that depicts the hierarchical structure of a View organized from the perspective of developers.

The yellow-colored ones are to be used by JVN iPedia. For the overall hierarchical structure of the CWE List, please refer to PDFs with Graphical Depictions of CWE (1.5).

IPA will revise the weakness types, analyzing the vulnerabilities published on JVN iPedia, and consider expanding them to include the deeper level of weakness types to support frequently-reported vulnerabilities.

Figure1. Weakness Used by JVN iPedia

Figure1. Hierarchical Structure of Weakness Types Used by JVN iPedia

4.Weakness Types Used by JVN iPedia

Table 2 is a list of weakness types to be used by JVN iPedia.
From #20 to #23 are weakness types not classifiable by CWE-635, #20 corresponds to a CWE other than CWE-635, #21 is not classifiable by CWE, #22 needs more information to determine and #23 is about design problem.

Table 2. Weakness Types Used by JVN iPedia







Configuration Weaknesses in this category are typically introduced during the configuration of the software.



Improper Input Validation The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.



Path Traversal The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly sanitize special elements that can resolve to a location that is outside of that directory.



Link Following The software attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.



OS Command Injection The software constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not sanitize or incorrectly sanitizes special elements that could modify the intended OS command when it is sent to a downstream component.



Cross-site scripting (XSS) The software does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.



SQL Injection The software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.



Code Injection The software constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.



Improper Restriction of Operations within the Bounds of a Memory Buffer (Buffer Errors) The software performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.



Use of Externally-Controlled Format String The software uses a function that accepts a format string as an argument, but the format string originates from an external source.



Numeric Errors Weaknesses in this category are related to improper calculation or conversion of numbers.



Information Exposure (Information Disclosure/
Information Leak)
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.



Credentials Management Weaknesses in this category are related to the management of credentials.



Permissions, Privileges, and Access Controls Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.



Improper Authentication When an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct.



Cryptographic Issues Weaknesses in this category are related to the design and implementation of data confidentiality and integrity. Frequently these deal with the use of encoding techniques, encryption libraries, and hashing algorithms. The weaknesses in this category could lead to a degradation of the quality data if they are not addressed.



Cross-Site Request Forgery (CSRF) The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.



Race Condition The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.



Resource Management Errors Weaknesses in this category are related to improper management of system resources.



No Mapping JVN iPedia is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.



No Mapping The weakness type is not covered in the version of CWE that was used for mapping.



No Mapping There is insufficient information about the issue to classify it; details are unknown or unspecified.



No Mapping A vulnerability is characterized as a “Design error” if there exists no errors in the implementation or configuration of a system, but the initial design causes a vulnerability to exist.


(*1)CWE: Common Weakness Enumeration.

(*2)MITRE Corporation: A not-for-profit organization that provides information technology support and R&D development to the U.S. government.

(*3)NIST: National Institute of Standards and Technology. A federal agency that develops and promotes measurement, standards and technology.

(*4)NVD: National Vulnerability Database. A vulnerability database run by NIST.

(*5)OWASP: Open Web Application Security Project. An open, not-for-profit community dedicated to enhancing software security by developing open source software to secure Web applications and Web sites and promoting software security.

(*6)OWASP Top Ten Project: A security awareness promotion with which OWASP picks top ten of the most critical Web application security vulnerabilities.

(*7)JVN iPedia Upgraded to New Version.

(*8)Filtered Vulnerability Countermeasure Information Tool “MyJVN” Now Available.

Filtered Vulnerability Countermeasure Information Tool “MyJVN” English Version Released.



IT Security Center,
Information-technology Promotion Agency, Japan (ISEC/IPA)

Last Updated

April 5, 2022
Updated description in Table 2.
Aug 5, 2009
Adopt CWE 1.5
Jun 3, 2009
Adopt CWE 1.4
Sep 10, 2008