8/24/2016 CWE ­ CWE Glossary

Common Weakness
Enumeration
A Community­Developed Dictionary of Software Weakness Types

CWE Glossary
Document version: 0.6    Date: 2015­12­07

This is a draft document. It is intended to support maintenance of CWE, and to
educate and solicit feedback from a specific technical audience. This document
does not reflect any official position of the MITRE Corporation or its sponsors.
Copyright © 2015, The MITRE Corporation. All rights reserved. Permission is
granted to redistribute this document if this paragraph is not removed. This
document is subject to change without notice.

Author: CWE Team
URL: http://cwe.mitre.org/documents/glossary/index.html

Table of Contents

Activation Point Actor
Attacker Authentication
Authorization Base Weakness
Behavior CRUD
Canonicalization Canonicalize
Category Chain
Check Class Weakness
Cleanse Cleansing
Cleartext Composite
Compound Element Consequence
Control Sphere Crossover Point
Enforce Entry
Equivalence Explicit Slice
Filter Filtering
Graph Handle
ICTA Implicit Slice
Improper Incorrect
Information Exposure Insecure
Insufficient Interaction Point
Internal Leading
Loose Composite Manipulation
Missing Named Chain
Natural Hierarchy Neutralization
Neutralize Node
Permissions Pillar
file:///D:/Documents/pdf/CWE%20­%20CWE%20Glossary.html 1/12
8/24/2016 CWE ­ CWE Glossary

Plaintext Primary Weakness
Property Protection Mechanism
Reliance Resolution
Resolve Resource
Resultant Weakness SDLC
Sanitization Sanitize
Security Policy Slice
Special Element Sphere of Control
Trailing Trigger Point
Unexpected Variant
View Vulnerability
Weakness

Activation Point
a vulnerability theory term for the location in code at an attacker's "payload" can
be executed, i.e. when the attacker has caused the code to violate the intended
security policy. For example, in SQL injection, the code reads an input from a
parameter (interaction point), incorrectly checks the input for dangerous
characters (crossover point), inserts the input into a dynamically generated
query string, then sends the query string to the database server (trigger point),
then the query is processed by the server (activation point). See the
Vulnerability Theory paper for more details.

Actor
a vulnerability theory term that describes an entity that interacts with the
software or with other entities, such as a User, Service, Monitor (e.g. IDS),
Intermediary, and others.

Attacker
an actor who attempts to gain access to behaviors or resources that are outside
of the software's intended control sphere for that actor.

Authentication
the process of verifying that an actor has a specific real­world identity, typically
by checking for information that the software assumes can only be produced by
that actor. This is different than authorization, because authentication focuses
on verifying the identity of the actor, not what resources the actor can access.

Authorization
the process of determining whether an actor with a given identity is allowed to
have access to a resource, then granting access to that resource, as defined by
the implicit and explicit security policies for the system. This is different than
authentication, because authorization focuses on whether a given actor can
access a given resource, not in proving what the real­world identity of the actor
is.

file:///D:/Documents/pdf/CWE%20­%20CWE%20Glossary.html 2/12
8/24/2016 CWE ­ CWE Glossary

Base Weakness
a weakness that is described in an abstract fashion, but with sufficient details to
infer specific methods for detection and prevention. More general than a Variant
weakness, but more specific than a Class weakness.

Behavior
an action that the software takes, typically as implemented in code or as
represented by an algorithm. Could also refer to actions by other actors that are
not the system.

CRUD
acronym for "Create, Read, Update, Delete," a model for persistent storage of
data that is similar to the resource model in vulnerability theory.

Canonicalization
a behavior that converts or reduces an input/output to a single fixed form that
cannot be converted or reduced any further. In cases in which the input/output
is used as an identifier, canonicalization refers to the act of converting that
identifier. For example, when the current working directory is "/users/cwe," the
filename "../xyz" can be canonicalized to "/users/xyz."

Canonicalize
to perform Canonicalization.

Category
a CWE entry that contains a set of other entries that share a common
characteristic.

Chain
a Compound Element that is a sequence of two or more separate weaknesses
that can be closely linked together within software. One weakness, X, can
directly create the conditions that are necessary to cause another weakness, Y,
to enter a vulnerable condition. When this happens, CWE refers to X as
"primary" to Y, and Y is "resultant" from X. For example, in the named chain
CWE­691, an integer overflow (CWE­190) can lead to a buffer overflow (CWE­
120) if an integer overflow occurs while calculating the amount of memory to
allocate. In this case, the integer overflow would be primary to the buffer
overflow. Chains can involve more than two weaknesses, and in some cases,
they might have a tree­like structure.

Check
in the vulnerability theory model of error handling, to examine a resource, its
properties, or the system state to determine if they align with the expectations
of the software.
file:///D:/Documents/pdf/CWE%20­%20CWE%20Glossary.html 3/12
8/24/2016 CWE ­ CWE Glossary

Class Weakness
a weakness that is described in a very abstract fashion, typically independent of
any specific language or technology. More general than a Base weakness.

Cleanse
Use of this term is discouraged in names and descriptions for CWE weaknesses,
since it has too many different meanings in the industry and may cause
mapping errors. It is not precise enough for CWE's purpose. This decision was
made in CWE 1.9. Some entries may still use this term, but they will be modified
in future versions.

Cleansing
This term is discouraged for use in CWE.

Cleartext
Any information that is unencrypted, although it might be in an encoded form
that is not easily human­readable, such as base64 encoding. Some people use
the "plaintext" term to mean the same thing, but "plaintext" has a more precise
meaning within cryptography.

Composite
a Compound Element that consists of two or more distinct weaknesses, in which
all weaknesses must be present at the same time in order for a potential
vulnerability to arise. Removing any of the weaknesses eliminates or sharply
reduces the risk. One weakness, X, can be "broken down" into component
weaknesses Y and Z. For example, Symlink Following (CWE­61) is only possible
through a combination of several component weaknesses, including
predictability (CWE­340), inadequate permissions (CWE­275), and race
conditions (CWE­362). By eliminating any single component, a developer can
prevent the composite from becoming exploitable. There can be cases in which
one weakness might not be essential to a composite, but changes the nature of
the composite when it becomes a vulnerability; for example, NUL byte
interaction errors (CWE­626) can widen the scope of path traversal weaknesses
(CWE­22), which often limit which files could be accessed due to idiosyncrasies
in filename generation.

Compound Element
an Entry that closely associates two or more CWE entries. The CWE team's
research has shown that vulnerabilities often can be described in terms of the
interaction or co­occurrence of two or more weaknesses. In CWE 1.0, the only
types of compound elements are Chains and Composites, although other types
might be defined in later versions.

Consequence

file:///D:/Documents/pdf/CWE%20­%20CWE%20Glossary.html 4/12
8/24/2016 CWE ­ CWE Glossary

a fault ­ a behavior that is always incorrect if executed, i.e., conflicts with the
intended security policy.

Control Sphere
a vulnerability theory term for a set of resources and behaviors that are
accessible to a single actor, or a group of actors that all share the same security
restrictions. This set can be empty. A product's security model will typically
define multiple spheres, although this model might not be explicitly stated. For
example, a server might define one sphere for "administrators" who can create
new user accounts with subdirectories under /home/server/, and a second
sphere might cover the set of users who can create or delete files within their
own subdirectories. A third sphere might be "users who are authenticated to the
operating system on which the product is installed." Each sphere has different
sets of actors and allowable behaviors. Vulnerabilities can arise when the
boundaries of a control sphere are not properly enforced, or when a control
sphere is defined in a way that allows more actors or resources than the
developer or system operator intends. For example, an application might intend
to allow guest users to access files that are only within a given directory, but a
path traversal attack could allow access to files that are outside of that directory,
which are thus outside of the intended sphere of control.

Crossover Point
a vulnerability theory term for the location in code after which an expected
property is violated. This is likely to lead to incorrect actions at a later point. For
example, a programmer might use a regular expression to restrict an input
string to contain only digits, such as for a telephone number. After applying the
regular expression, the string is expected to have the property "only contains
digits." If the regular expression is incorrectly specified (e.g. only testing for the
presence of a digit anywhere in the string), then after its application, the code
reaches a crossover point because the string does not necessarily have the
property of "only contains digits." For example, in SQL injection, the code reads
an input from a parameter (interaction point), incorrectly checks the input for
dangerous characters (crossover point), inserts the input into a dynamically
generated query string, then sends the query string to the database server
(trigger point), then the query is processed by the server (activation point). See
the Vulnerability Theory paper for more details.

Enforce
a general term, meaning to check or manipulate a resource so that it has a
property that is required by the security policy. For example, the filtering of all
non­alphanumeric characters from an input is one mechanism to enforce that
"all characters are alphanumeric." An alternate method of enforcement would be
to reject the input entirely if it contains anything that's non­alphanumeric.

Entry
any type of item in the CWE list that has been assigned a unique identifier.

Equivalence

file:///D:/Documents/pdf/CWE%20­%20CWE%20Glossary.html 5/12
8/24/2016 CWE ­ CWE Glossary

a security property in which two identifiers, inputs, resources, or behaviors have
syntactically different representations, but are ultimately treated as being the
same. For example, in Windows systems, the filenames "MyFile.txt" and
"MYFILE.TXT" are equivalent because they refer to the same underlying file
object. The inability to recognize equivalence is often a factor in vulnerabilities.

Explicit Slice
a Slice whose membership is determined by some external criterion that is
represented using HasMember relationships between the view and those entries,
but not between entries themselves. An example is CWE­635, which lists the
CWE identifiers that being used by NVD.

Filter
to perform Filtering.

Filtering
the removal of elements from input or output based on some criteria. This term
may apply to removal of elements regardless of security implications.

Graph
a View that specifies relationships between entries, typically of a hierarchical
nature. The root level nodes of the view are specified using HasMember
relationships. Children are specified using ChildOf or other relationships.

Handle
in the vulnerability theory model of error handling, to modify the execution of
the software based on the results of a check for an error or exceptional
condition.

ICTA
Interaction/Crossover/Trigger/Activation, an acronym for the vulnerability theory
terms for important locations in code artifacts.

Implicit Slice
a Slice that defines its membership based on common characteristics of entries,
such as weaknesses that can appear in C programs (CWE­658).

Improper
used as a catch­all term to cover security behaviors that are either "Missing" or
"Insufficient/Incorrect." Note: this term is being used inconsistently in CWE,
although it has been more clearly defined since CWE 1.2.

Incorrect
file:///D:/Documents/pdf/CWE%20­%20CWE%20Glossary.html 6/12
8/24/2016 CWE ­ CWE Glossary

a general term, used to describe when a behavior attempts to do a task but
does not do it correctly. This is distinct from "Missing," in which the developer
does not even attempt to perform the behavior. This is similar to "Insufficient."
Note: this term is being used inconsistently in CWE, although it has been more
clearly defined since CWE 1.2.

Information Exposure
the intentional or unintentional disclosure of information to an actor that is not
explicitly authorized to have access to that information.

Insecure
Use of this term is discouraged in names and descriptions for CWE weaknesses,
since it does not provide any hint about the actual error that was introduced by
the developer. Some unreviewed entries may still use this term, although it will
be corrected in future versions of CWE. This is a general term used to describe a
behavior that is incorrect and has security implications.

Insufficient
a general term used to describe when a security property or behavior can vary
in strength on a continuous or sliding scale, instead of a discrete scale. The
continuous scale may vary depending on the context and risk tolerance. For
example, the requirements for randomness may vary between a random
selection for a greeting message versus the generation of a military­strength
key. On the other hand, a weakness that allows a buffer overflow is always
incorrect ­ there is not a sliding scale that varies across contexts. Note: this this
term has been used inconsistently in CWE, although it was more clearly defined
beginning in CWE 1.4.

Interaction Point
a vulnerability theory term for the point in code from which input is obtained
from the external environment. For example, in SQL injection, the code reads an
input from a parameter (interaction point), incorrectly checks the input for
dangerous characters (crossover point), inserts the input into a dynamically
generated query string, then sends the query string to the database server
(trigger point), then the query is processed by the server (activation point). See
the Vulnerability Theory paper for more details.

Internal
used to describe a manipulation that occurs within an identifier or input, and not
at the beginning or the end. This term is often used in conjunction with special
elements. For example, the string "/etc//passwd" has multiple internal "/"
characters, or "<SCRI.PT>" has an internal "." character.

Leading
1) used to describe a manipulation that occurs at the beginning of an identifier
or input. This term is often used in conjunction with special elements. For

file:///D:/Documents/pdf/CWE%20­%20CWE%20Glossary.html 7/12
8/24/2016 CWE ­ CWE Glossary

example, the string "//etc/passwd" has multiple leading "/" characters. 2) used
to describe the transition from a primary to resultant weakness in a chain

Loose Composite
an informal term for describing a CWE entry that the general public thinks of as
an individual weakness, but is actually a disjoint list of multiple distinct
weaknesses ­ i.e., a narrowly­defined category. This is not well­handled within
CWE 1.0, although it might be regarded as another kind of Compound Element.
An example of a loose composite is "insecure temporary file" ­ the temporary file
could have permissions problems, be used as a semaphore, be part of a race
condition, etc.

Manipulation
the modification of a resource by an actor, typically to change its properties.
Usually used in the context of software as it manipulates inputs and system
resources to ensure that security properties are enforced.

Missing
used to describe a behavior that the developer has not attempted to perform.
This is distinct from "incorrect," which describes when the developer attempts to
perform the behavior, but does not do it correctly. Note: this term is being used
inconsistently in CWE, although it has been more clearly defined since CWE 1.2.

Named Chain
a Chain that appears so frequently in software that a CWE ID has been assigned
to it, such as CWE­680 (Integer Overflow to Buffer Overflow).

Natural Hierarchy
the term used in Draft 9 for the Research Concepts View (CWE­1000).

Neutralization
a general term to describe the process of ensuring that input or output has
certain security properties before it is used. This is independent of the specific
protection mechanism that performs the neutralization. The term could refer to
one or more of the following: filtering/cleansing, canonicalization/resolution,
encoding/decoding, escaping/unescaping, quoting/unquoting, validation, or
other mechanisms.

Neutralize
to perform Neutralization.

Node
another term for a CWE entry, especially used before CWE 1.0.

file:///D:/Documents/pdf/CWE%20­%20CWE%20Glossary.html 8/12
8/24/2016 CWE ­ CWE Glossary

Permissions
the explicit specifications for a resource, or a set of resources, that defines
which actors are allowed to access that resource, and which actions may be
performed by those actors. Permissions can contribute to the definition of one or
more intended control spheres.

Pillar
a top­level entry in the Research Concepts View (CWE­1000). Equivalent to
"kingdoms" in Seven Pernicious Kingdoms.

Plaintext
information that is used as the input to an encryption algorithm, which might
contain already­encrypted text. Many people use the "plaintext" term to mean
"unencrypted," and others may use "cleartext" to mean the same thing.

Primary Weakness
a weakness that is an initial, critical error (root cause) that can expose other
weaknesses later in execution of the software.

Property
a vulnerability theory term for the security­relevant characteristic of an
individual resource or behavior that is important to the system's intended
security model, which might change over time. For example, user input is
initially untrusted; after the system neutralizes the input, when the input is
finally processed, it must be treated as trusted. This illustrates the Trustability
property.

Protection Mechanism
a vulnerability theory term for a set of behaviors that helps to enforce an
implicit or explicit security policy for the software, such as an input validation
routine.

Reliance
a security­relevant assumption that a resource has a given property, which can
lead to weaknesses if that property cannot be guaranteed. For example, an
access control protection mechanism might use reverse DNS lookups (CWE­247)
in an attempt to limit access to systems in a particular domain; however, this
reliance on DNS introduces a weakness because DNS results can be spoofed.

Resolution
the process of converting a resource identifier to a single, canonical form. For
example, code that converts "/tmp/abc/../def.xyz" to "/tmp/def.xyz" is
performing resolution on an identifier that is being used for a file resource.

file:///D:/Documents/pdf/CWE%20­%20CWE%20Glossary.html 9/12
8/24/2016 CWE ­ CWE Glossary

Resolve
to perform Resolution.

Resource
a vulnerability theory term for an object or entity that is accessed or modified
within the operation of the software, such as memory, CPU, files, or sockets.
Resources can be system­level (memory or CPU), code­level (function or
variable), or application­level (cookie or message).

Resultant Weakness
a weakness that is only exposed to attack after another weakness has been
exploited; an early link in a chain.

SDLC
Software Development Lifecycle.

Sanitization
Use of this term is discouraged in names and descriptions for CWE weaknesses,
since it has too many different meanings in the industry and may cause
mapping errors. It is not precise enough for CWE's purpose. This decision was
made in CWE 1.8.1. Some entries may still use this term, but they will be
modified in future versions. Similar terms in use in CWE may include
"Neutralization," "Validation," "Encoding," and "Filtering."

Sanitize
This term is discouraged for use in CWE.

Security Policy
in vulnerability theory, a set of valid behaviors, properties, and resources within
the context of operation of a software system. The policy is generally implicit (as
reflected in the code, or the programmer's assumptions), but it can be explicit.

Slice
a view that is a flat list of CWE entries that does not specify any relationships
between those entries.

Special Element
a general term for a sequence of bytes, characters, or words that is used to
separate different portions of data within a particular representation or
language. The most commonly understood usage of special elements is in single
characters, such as the "<" in HTML, which marks the beginning of a tag. As
another example, the CRLF (carriage return / line feed) character is used as a
separator between headers in MIME messages, so CRLF is a special element.
file:///D:/Documents/pdf/CWE%20­%20CWE%20Glossary.html 10/12
 separator between headers in MIME messages, so CRLF is a special element.
8/24/2016 CWE ­ CWE Glossary

When multi­part MIME messages are constructed, the boundary string becomes
a special element. Special elements are often important in weaknesses that can
be exploited by injection attacks. A special element in one representation might
not be special in another. For example, whitespace is a special element when
executing a command in a shell (since it acts as an argument separator), but it
has no special meaning in the body of HTML or e­mail messages.

Sphere of Control
See Control Sphere

Trailing
used to describe a manipulation that occurs at the end of an identifier or input.
This term is often used in conjunction with special elements. For example, the
string "example.com." has a trailing "." character.

Trigger Point
a vulnerability theory term for the location in code after which the software can
no longer prevent itself from violating the intended security policy. For example,
in SQL injection, the code reads an input from a parameter (interaction point),
incorrectly checks the input for dangerous characters (crossover point), inserts
the input into a dynamically generated query string, then sends the query string
to the database server (trigger point), then the query is processed by the server
(activation point). See the Vulnerability Theory paper for more details.

Unexpected
violating the assumptions of the developer or operator of the software. This is
typically used to describe the state of the software, a behavior that was not
intended, or a property of a resource that was not assumed to be present. For
example, if an e­commerce program allows a user to specify the quantity of
items to purchase, and the program assumes that the quantity will be a number,
then the string "abcde" is unexpected. A program crash is usually unexpected
behavior. Similarly, when a programmer dereferences a pointer, it is usually
unexpected if that pointer can be NULL. Attacks often leverage unexpected
properties and behaviors, since the developer has not necessarily provided a
sufficient defense.

Variant
a weakness that is described at a very low level of detail, typically limited to a
specific language or technology. More specific than a Base weakness.

View
a subset of CWE entries that provides a way of examining CWE content. The two
main view structures are Slices (flat lists) and Graphs (containing relationships
between entries).

Vulnerability
file:///D:/Documents/pdf/CWE%20­%20CWE%20Glossary.html 11/12
8/24/2016 CWE ­ CWE Glossary

an occurrence of a weakness (or multiple weaknesses) within software, in which
the weakness can be used by a party to cause the software to modify or access
unintended data, interrupt proper execution, or perform incorrect actions that
were not specifically granted to the party who uses the weakness.

Weakness
a type of mistake in software that, in proper conditions, could contribute to the
introduction of vulnerabilities within that software. This term applies to mistakes
regardless of whether they occur in implementation, design, or other phases of
the SDLC.

Use of the Common Weakness Enumeration and the associated references from this website are subject to the Terms Privacy policy
of Use. For more information, please email cwe@mitre.org. Terms of use
Contact us
CWE is sponsored by US­CERT in the office of Cybersecurity and Communications at the U.S. Department of Homeland
Security. Copyright © 2006­2015, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of
The MITRE Corporation.

file:///D:/Documents/pdf/CWE%20­%20CWE%20Glossary.html 12/12