CWE

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > VIEW SLICE: CWE-1008: Architectural Concepts (4.16)  
ID

CWE VIEW: Architectural Concepts

View ID: 1008
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
Type: Graph
Downloads: Booklet | CSV | XML
+ Objective
This view organizes weaknesses according to common architectural security tactics. It is intended to assist architects in identifying potential mistakes that can be made when designing software.
+ Audience
Stakeholder Description
Software Developers Architects that are part of a software development team may find this view useful as the weaknesses are organized by known security tactics, aiding the arcitect in embedding security throughout the design process instead of discovering weaknesses after the software has been built.
Educators Educators may use this view as reference material when discussing security by design or architectural weaknesses, and the types of mistakes that can be made.
+ Relationships
The following graph shows the tree-like relationships between weaknesses that exist at different levels of abstraction. At the highest level, categories and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are special CWE entries used to group weaknesses that share a common characteristic. Pillars are weaknesses that are described in the most abstract fashion. Below these top-level entries are weaknesses are varying levels of abstraction. Classes are still very abstract, typically independent of any specific language or technology. Base level weaknesses are used to present a more specific type of weakness. A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. While a composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability.
Show Details:
1008 - Architectural Concepts
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Audit - (1009)
1008 (Architectural Concepts) > 1009 (Audit)
Weaknesses in this category are related to the design and architecture of audit-based components of the system. Frequently these deal with logging user activities in order to identify attackers and modifications to the system. The weaknesses in this category could lead to a degradation of the quality of the audit capability if they are not addressed when designing or implementing a secure architecture.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Output Neutralization for Logs - (117)
1008 (Architectural Concepts) > 1009 (Audit) > 117 (Improper Output Neutralization for Logs)
The product does not neutralize or incorrectly neutralizes output that is written to logs.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Omission of Security-relevant Information - (223)
1008 (Architectural Concepts) > 1009 (Audit) > 223 (Omission of Security-relevant Information)
The product does not record or display information that would be important for identifying the source or nature of an attack, or determining if an action is safe.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Obscured Security-relevant Information by Alternate Name - (224)
1008 (Architectural Concepts) > 1009 (Audit) > 224 (Obscured Security-relevant Information by Alternate Name)
The product records security-relevant information according to an alternate name of the affected entity, instead of the canonical name.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Insertion of Sensitive Information into Log File - (532)
1008 (Architectural Concepts) > 1009 (Audit) > 532 (Insertion of Sensitive Information into Log File)
The product writes sensitive information to a log file.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Insufficient Logging - (778)
1008 (Architectural Concepts) > 1009 (Audit) > 778 (Insufficient Logging)
When a security-critical event occurs, the product either does not record the event or omits important details about the event when logging it.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Logging of Excessive Data - (779)
1008 (Architectural Concepts) > 1009 (Audit) > 779 (Logging of Excessive Data)
The product logs too much information, making log files hard to process and possibly hindering recovery efforts or forensic analysis after an attack.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Authenticate Actors - (1010)
1008 (Architectural Concepts) > 1010 (Authenticate Actors)
Weaknesses in this category are related to the design and architecture of authentication components of the system. Frequently these deal with verifying the entity is indeed who it claims to be. The weaknesses in this category could lead to a degradation of the quality of authentication if they are not addressed when designing or implementing a secure architecture.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Empty Password in Configuration File - (258)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 258 (Empty Password in Configuration File)
Using an empty string as a password is insecure.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of Hard-coded Password - (259)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 259 (Use of Hard-coded Password)
The product contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Not Using Password Aging - (262)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 262 (Not Using Password Aging)
The product does not have a mechanism in place for managing password aging.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Password Aging with Long Expiration - (263)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 263 (Password Aging with Long Expiration)
The product supports password aging, but the expiration period is too long.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Authentication - (287)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 287 (Improper Authentication)
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. authentification AuthN AuthC
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Authentication Bypass Using an Alternate Path or Channel - (288)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 288 (Authentication Bypass Using an Alternate Path or Channel)
The product requires authentication, but the product has an alternate path or channel that does not require authentication.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Authentication Bypass by Alternate Name - (289)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 289 (Authentication Bypass by Alternate Name)
The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Authentication Bypass by Spoofing - (290)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 290 (Authentication Bypass by Spoofing)
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Reliance on IP Address for Authentication - (291)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 291 (Reliance on IP Address for Authentication)
The product uses an IP address for authentication.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Using Referer Field for Authentication - (293)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 293 (Using Referer Field for Authentication)
The referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking. referrer
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Authentication Bypass by Capture-replay - (294)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 294 (Authentication Bypass by Capture-replay)
A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Reflection Attack in an Authentication Protocol - (301)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 301 (Reflection Attack in an Authentication Protocol)
Simple authentication protocols are subject to reflection attacks if a malicious user can use the target machine to impersonate a trusted user.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Authentication Bypass by Assumed-Immutable Data - (302)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 302 (Authentication Bypass by Assumed-Immutable Data)
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Implementation of Authentication Algorithm - (303)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 303 (Incorrect Implementation of Authentication Algorithm)
The requirements for the product dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Critical Step in Authentication - (304)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 304 (Missing Critical Step in Authentication)
The product implements an authentication technique, but it skips a step that weakens the technique.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Authentication Bypass by Primary Weakness - (305)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 305 (Authentication Bypass by Primary Weakness)
The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Authentication for Critical Function - (306)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 306 (Missing Authentication for Critical Function)
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Restriction of Excessive Authentication Attempts - (307)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 307 (Improper Restriction of Excessive Authentication Attempts)
The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Single-factor Authentication - (308)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 308 (Use of Single-factor Authentication)
The use of single-factor authentication can lead to unnecessary risk of compromise when compared with the benefits of a dual-factor authentication scheme.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Key Exchange without Entity Authentication - (322)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 322 (Key Exchange without Entity Authentication)
The product performs a key exchange with an actor without verifying the identity of that actor.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Weak Password Requirements - (521)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 521 (Weak Password Requirements)
The product does not require that users should have strong passwords, which makes it easier for attackers to compromise user accounts.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created - (593)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 593 (Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created)
The product modifies the SSL context after connection creation has begun.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Client-Side Authentication - (603)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 603 (Use of Client-Side Authentication)
A client/server product performs authentication within client code but not in server code, allowing server-side authentication to be bypassed via a modified client that omits the authentication check.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unverified Password Change - (620)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 620 (Unverified Password Change)
When setting a new password for a user, the product does not require knowledge of the original password, or using another form of authentication.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Weak Password Recovery Mechanism for Forgotten Password - (640)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 640 (Weak Password Recovery Mechanism for Forgotten Password)
The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Hard-coded Credentials - (798)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 798 (Use of Hard-coded Credentials)
The product contains hard-coded credentials, such as a password or cryptographic key.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Password Hash Instead of Password for Authentication - (836)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 836 (Use of Password Hash Instead of Password for Authentication)
The product records password hashes in a data store, receives a hash of a password from a client, and compares the supplied hash to the hash obtained from the data store.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Password Hash With Insufficient Computational Effort - (916)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 916 (Use of Password Hash With Insufficient Computational Effort)
The product generates a hash for a password, but it uses a scheme that does not provide a sufficient level of computational effort that would make password cracking attacks infeasible or expensive.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Authorize Actors - (1011)
1008 (Architectural Concepts) > 1011 (Authorize Actors)
Weaknesses in this category are related to the design and architecture of a system's authorization components. Frequently these deal with enforcing that agents have the required permissions before performing certain operations, such as modifying data. The weaknesses in this category could lead to a degradation of quality of the authorization capability if they are not addressed when designing or implementing a secure architecture.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Process Control - (114)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 114 (Process Control)
Executing commands or loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands (and payloads) on behalf of an attacker.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. External Control of System or Configuration Setting - (15)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 15 (External Control of System or Configuration Setting)
One or more system settings or configuration elements can be externally controlled by a user.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Storage of File with Sensitive Data Under Web Root - (219)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 219 (Storage of File with Sensitive Data Under Web Root)
The product stores sensitive data under the web document root with insufficient access control, which might make it accessible to untrusted parties.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Storage of File With Sensitive Data Under FTP Root - (220)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 220 (Storage of File With Sensitive Data Under FTP Root)
The product stores sensitive data under the FTP server root with insufficient access control, which might make it accessible to untrusted parties.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Privilege Assignment - (266)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 266 (Incorrect Privilege Assignment)
A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Privilege Defined With Unsafe Actions - (267)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 267 (Privilege Defined With Unsafe Actions)
A particular privilege, role, capability, or right can be used to perform unsafe actions that were not intended, even when it is assigned to the correct entity.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Privilege Chaining - (268)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 268 (Privilege Chaining)
Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Privilege Management - (269)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 269 (Improper Privilege Management)
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Privilege Context Switching Error - (270)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 270 (Privilege Context Switching Error)
The product does not properly manage privileges while it is switching between different contexts that have different privileges or spheres of control.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Privilege Dropping / Lowering Errors - (271)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 271 (Privilege Dropping / Lowering Errors)
The product does not drop privileges before passing control of a resource to an actor that does not have those privileges.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Least Privilege Violation - (272)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 272 (Least Privilege Violation)
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Check for Dropped Privileges - (273)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 273 (Improper Check for Dropped Privileges)
The product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Insufficient Privileges - (274)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 274 (Improper Handling of Insufficient Privileges)
The product does not handle or incorrectly handles when it has insufficient privileges to perform an operation, leading to resultant weaknesses.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Default Permissions - (276)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 276 (Incorrect Default Permissions)
During installation, installed file permissions are set to allow anyone to modify those files.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Insecure Inherited Permissions - (277)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 277 (Insecure Inherited Permissions)
A product defines a set of insecure permissions that are inherited by objects that are created by the program.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Execution-Assigned Permissions - (279)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 279 (Incorrect Execution-Assigned Permissions)
While it is executing, the product sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Insufficient Permissions or Privileges - (280)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 280 (Improper Handling of Insufficient Permissions or Privileges )
The product does not handle or incorrectly handles when it has insufficient privileges to access resources or functionality as specified by their permissions. This may cause it to follow unexpected code paths that may leave the product in an invalid state.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Preservation of Permissions - (281)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 281 (Improper Preservation of Permissions)
The product does not preserve permissions or incorrectly preserves permissions when copying, restoring, or sharing objects, which can cause them to have less restrictive permissions than intended.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Ownership Management - (282)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 282 (Improper Ownership Management)
The product assigns the wrong ownership, or does not properly verify the ownership, of an object or resource.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unverified Ownership - (283)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 283 (Unverified Ownership)
The product does not properly verify that a critical resource is owned by the proper entity.
* Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. Improper Access Control - (284)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 284 (Improper Access Control)
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. Authorization
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Authorization - (285)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 285 (Improper Authorization)
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. AuthZ
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect User Management - (286)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 286 (Incorrect User Management)
The product does not properly manage a user within its environment.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Channel Accessible by Non-Endpoint - (300)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 300 (Channel Accessible by Non-Endpoint)
The product does not adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint. Adversary-in-the-Middle / AITM Man-in-the-Middle / MITM Person-in-the-Middle / PITM Monkey-in-the-Middle Monster-in-the-Middle Manipulator-in-the-Middle On-path attack Interception attack
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Predictable from Observable State - (341)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 341 (Predictable from Observable State)
A number or object is predictable based on observations that the attacker can make about the state of the system or network, such as time, process ID, etc.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Private Personal Information to an Unauthorized Actor - (359)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 359 (Exposure of Private Personal Information to an Unauthorized Actor)
The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected. Privacy violation Privacy leak Privacy leakage
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak') - (403)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 403 (Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak'))
A process does not close sensitive file descriptors before invoking a child process, which allows the child to perform unauthorized I/O operations using those descriptors. File descriptor leak
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unprotected Primary Channel - (419)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 419 (Unprotected Primary Channel)
The product uses a primary channel for administration or restricted functionality, but it does not properly protect the channel.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unprotected Alternate Channel - (420)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 420 (Unprotected Alternate Channel)
The product protects a primary channel, but it does not use the same level of protection for an alternate channel.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Direct Request ('Forced Browsing') - (425)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 425 (Direct Request ('Forced Browsing'))
The web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files. forced browsing
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Untrusted Search Path - (426)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 426 (Untrusted Search Path)
The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control. Untrusted Path
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unrestricted Upload of File with Dangerous Type - (434)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 434 (Unrestricted Upload of File with Dangerous Type)
The product allows the upload or transfer of dangerous file types that are automatically processed within its environment. Unrestricted File Upload
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Version-Control Repository to an Unauthorized Control Sphere - (527)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 527 (Exposure of Version-Control Repository to an Unauthorized Control Sphere)
The product stores a CVS, git, or other repository in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized actors.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Core Dump File to an Unauthorized Control Sphere - (528)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 528 (Exposure of Core Dump File to an Unauthorized Control Sphere)
The product generates a core dump file in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized actors.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Access Control List Files to an Unauthorized Control Sphere - (529)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 529 (Exposure of Access Control List Files to an Unauthorized Control Sphere)
The product stores access control list files in a directory or other container that is accessible to actors outside of the intended control sphere.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Backup File to an Unauthorized Control Sphere - (530)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 530 (Exposure of Backup File to an Unauthorized Control Sphere)
A backup file is stored in a directory or archive that is made accessible to unauthorized actors.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Insertion of Sensitive Information into Externally-Accessible File or Directory - (538)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 538 (Insertion of Sensitive Information into Externally-Accessible File or Directory)
The product places sensitive information into files or directories that are accessible to actors who are allowed to have access to the files, but not to the sensitive information.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Behavior Order: Authorization Before Parsing and Canonicalization - (551)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 551 (Incorrect Behavior Order: Authorization Before Parsing and Canonicalization)
If a web server does not fully parse requested URLs before it examines them for authorization, it may be possible for an attacker to bypass authorization protection.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Files or Directories Accessible to External Parties - (552)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 552 (Files or Directories Accessible to External Parties)
The product makes files or directories accessible to unauthorized actors, even though they should not be.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Authorization Bypass Through User-Controlled SQL Primary Key - (566)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 566 (Authorization Bypass Through User-Controlled SQL Primary Key)
The product uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Authorization Bypass Through User-Controlled Key - (639)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 639 (Authorization Bypass Through User-Controlled Key)
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. Insecure Direct Object Reference / IDOR Broken Object Level Authorization / BOLA Horizontal Authorization
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. External Control of Critical State Data - (642)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 642 (External Control of Critical State Data)
The product stores security-critical state information about its users, or the product itself, in a location that is accessible to unauthorized actors.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of Non-Canonical URL Paths for Authorization Decisions - (647)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 647 (Use of Non-Canonical URL Paths for Authorization Decisions)
The product defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Isolation or Compartmentalization - (653)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 653 (Improper Isolation or Compartmentalization)
The product does not properly compartmentalize or isolate functionality, processes, or resources that require different privilege levels, rights, or permissions. Separation of Privilege
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Reliance on Security Through Obscurity - (656)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 656 (Reliance on Security Through Obscurity)
The product uses a protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism. Never Assuming your secrets are safe
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Exposure of Resource to Wrong Sphere - (668)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 668 (Exposure of Resource to Wrong Sphere)
The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Resource Transfer Between Spheres - (669)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 669 (Incorrect Resource Transfer Between Spheres)
The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Lack of Administrator Control over Security - (671)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 671 (Lack of Administrator Control over Security)
The product uses security features in a way that prevents the product's administrator from tailoring security settings to reflect the environment in which the product is being used. This introduces resultant weaknesses or prevents it from operating at a level of security that is desired by the administrator.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. External Influence of Sphere Definition - (673)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 673 (External Influence of Sphere Definition)
The product does not prevent the definition of control spheres from external actors.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Ownership Assignment - (708)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 708 (Incorrect Ownership Assignment)
The product assigns an owner to a resource, but the owner is outside of the intended control sphere.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Permission Assignment for Critical Resource - (732)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 732 (Incorrect Permission Assignment for Critical Resource)
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Allocation of Resources Without Limits or Throttling - (770)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 770 (Allocation of Resources Without Limits or Throttling)
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Exposed IOCTL with Insufficient Access Control - (782)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 782 (Exposed IOCTL with Insufficient Access Control)
The product implements an IOCTL with functionality that should be restricted, but it does not properly enforce access control for the IOCTL.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Control of Document Type Definition - (827)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 827 (Improper Control of Document Type Definition)
The product does not restrict a reference to a Document Type Definition (DTD) to the intended control sphere. This might allow attackers to reference arbitrary DTDs, possibly causing the product to expose files, consume excessive system resources, or execute arbitrary http requests on behalf of the attacker.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Missing Authorization - (862)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 862 (Missing Authorization)
The product does not perform an authorization check when an actor attempts to access a resource or perform an action. AuthZ
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Authorization - (863)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 863 (Incorrect Authorization)
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. AuthZ
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Storage of Sensitive Data in a Mechanism without Access Control - (921)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 921 (Storage of Sensitive Data in a Mechanism without Access Control)
The product stores sensitive information in a file system or device that does not have built-in access control.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Restriction of Communication Channel to Intended Endpoints - (923)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 923 (Improper Restriction of Communication Channel to Intended Endpoints)
The product establishes a communication channel to (or from) an endpoint for privileged or protected operations, but it does not properly ensure that it is communicating with the correct endpoint.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Authorization in Handler for Custom URL Scheme - (939)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 939 (Improper Authorization in Handler for Custom URL Scheme)
The product uses a handler for a custom URL scheme, but it does not properly restrict which actors can invoke the handler using the scheme.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Permissive Cross-domain Policy with Untrusted Domains - (942)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 942 (Permissive Cross-domain Policy with Untrusted Domains)
The product uses a cross-domain policy file that includes domains that should not be trusted.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Cross Cutting - (1012)
1008 (Architectural Concepts) > 1012 (Cross Cutting)
Weaknesses in this category are related to the design and architecture of multiple security tactics and how they affect a system. For example, information exposure can impact the Limit Access and Limit Exposure security tactics. The weaknesses in this category could lead to a degradation of the quality of many capabilities if they are not addressed when designing or implementing a secure architecture.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Observable Timing Discrepancy - (208)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 208 (Observable Timing Discrepancy)
Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Report of Error Condition - (392)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 392 (Missing Report of Error Condition)
The product encounters an error but does not provide a status code or return value to indicate that an error has occurred.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Cleanup on Thrown Exception - (460)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 460 (Improper Cleanup on Thrown Exception)
The product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Standardized Error Handling Mechanism - (544)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 544 (Missing Standardized Error Handling Mechanism)
The product does not use a standardized method for handling errors throughout the code, which might introduce inconsistent error handling and resultant weaknesses.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Client-Side Enforcement of Server-Side Security - (602)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 602 (Client-Side Enforcement of Server-Side Security)
The product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
* Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. Improper Check or Handling of Exceptional Conditions - (703)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 703 (Improper Check or Handling of Exceptional Conditions)
The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Check for Unusual or Exceptional Conditions - (754)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 754 (Improper Check for Unusual or Exceptional Conditions)
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Reliance on Cookies without Validation and Integrity Checking in a Security Decision - (784)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 784 (Reliance on Cookies without Validation and Integrity Checking in a Security Decision)
The product uses a protection mechanism that relies on the existence or values of a cookie, but it does not properly ensure that the cookie is valid for the associated user.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Reliance on Untrusted Inputs in a Security Decision - (807)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 807 (Reliance on Untrusted Inputs in a Security Decision)
The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Encrypt Data - (1013)
1008 (Architectural Concepts) > 1013 (Encrypt Data)
Weaknesses in this category are related to the design and architecture of data confidentiality in a system. Frequently these deal with the use of encryption libraries. The weaknesses in this category could lead to a degradation of the quality data encryption if they are not addressed when designing or implementing a secure architecture.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Plaintext Storage of a Password - (256)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 256 (Plaintext Storage of a Password)
Storing a password in plaintext may result in a system compromise.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Storing Passwords in a Recoverable Format - (257)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 257 (Storing Passwords in a Recoverable Format)
The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. In fact, it should be noted that recoverable encrypted passwords provide no significant benefit over plaintext passwords since they are subject not only to reuse by malicious attackers but also by malicious insiders. If a system administrator can recover a password directly, or use a brute force search on the available information, the administrator can use the password on other accounts.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Password in Configuration File - (260)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 260 (Password in Configuration File)
The product stores a password in a configuration file that might be accessible to actors who do not know the password.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Weak Encoding for Password - (261)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 261 (Weak Encoding for Password)
Obscuring a password with a trivial encoding does not protect the password.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Missing Encryption of Sensitive Data - (311)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 311 (Missing Encryption of Sensitive Data)
The product does not encrypt sensitive or critical information before storage or transmission.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Storage of Sensitive Information - (312)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 312 (Cleartext Storage of Sensitive Information)
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Storage in a File or on Disk - (313)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 313 (Cleartext Storage in a File or on Disk)
The product stores sensitive information in cleartext in a file, or on disk.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Storage in the Registry - (314)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 314 (Cleartext Storage in the Registry)
The product stores sensitive information in cleartext in the registry.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Storage of Sensitive Information in a Cookie - (315)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 315 (Cleartext Storage of Sensitive Information in a Cookie)
The product stores sensitive information in cleartext in a cookie.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Storage of Sensitive Information in Memory - (316)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 316 (Cleartext Storage of Sensitive Information in Memory)
The product stores sensitive information in cleartext in memory.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Storage of Sensitive Information in GUI - (317)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 317 (Cleartext Storage of Sensitive Information in GUI)
The product stores sensitive information in cleartext within the GUI.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Storage of Sensitive Information in Executable - (318)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 318 (Cleartext Storage of Sensitive Information in Executable)
The product stores sensitive information in cleartext in an executable.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Transmission of Sensitive Information - (319)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 319 (Cleartext Transmission of Sensitive Information)
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of Hard-coded Cryptographic Key - (321)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 321 (Use of Hard-coded Cryptographic Key)
The use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Reusing a Nonce, Key Pair in Encryption - (323)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 323 (Reusing a Nonce, Key Pair in Encryption)
Nonces should be used for the present occasion and only once.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of a Key Past its Expiration Date - (324)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 324 (Use of a Key Past its Expiration Date)
The product uses a cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attacks against that key.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Cryptographic Step - (325)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 325 (Missing Cryptographic Step)
The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Inadequate Encryption Strength - (326)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 326 (Inadequate Encryption Strength)
The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Use of a Broken or Risky Cryptographic Algorithm - (327)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 327 (Use of a Broken or Risky Cryptographic Algorithm)
The product uses a broken or risky cryptographic algorithm or protocol.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Weak Hash - (328)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 328 (Use of Weak Hash)
The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Use of Insufficiently Random Values - (330)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 330 (Use of Insufficiently Random Values)
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Insufficient Entropy - (331)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 331 (Insufficient Entropy)
The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Insufficient Entropy in PRNG - (332)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 332 (Insufficient Entropy in PRNG)
The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Insufficient Entropy in TRNG - (333)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 333 (Improper Handling of Insufficient Entropy in TRNG)
True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Small Space of Random Values - (334)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 334 (Small Space of Random Values)
The number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG) - (335)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 335 (Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG))
The product uses a Pseudo-Random Number Generator (PRNG) but does not correctly manage seeds.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Same Seed in Pseudo-Random Number Generator (PRNG) - (336)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 336 (Same Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Predictable Seed in Pseudo-Random Number Generator (PRNG) - (337)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 337 (Predictable Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) - (338)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 338 (Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG))
The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Small Seed Space in PRNG - (339)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 339 (Small Seed Space in PRNG)
A Pseudo-Random Number Generator (PRNG) uses a relatively small seed space, which makes it more susceptible to brute force attacks.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Verification of Cryptographic Signature - (347)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 347 (Improper Verification of Cryptographic Signature)
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Insufficiently Protected Credentials - (522)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 522 (Insufficiently Protected Credentials)
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unprotected Transport of Credentials - (523)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 523 (Unprotected Transport of Credentials)
Login pages do not use adequate measures to protect the user name and password while they are in transit from the client to the server.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade') - (757)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 757 (Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade'))
A protocol or its implementation supports interaction between multiple actors and allows those actors to negotiate which algorithm should be used as a protection mechanism such as encryption or authentication, but it does not select the strongest algorithm that is available to both parties.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of a One-Way Hash without a Salt - (759)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 759 (Use of a One-Way Hash without a Salt)
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product does not also use a salt as part of the input.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of a One-Way Hash with a Predictable Salt - (760)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 760 (Use of a One-Way Hash with a Predictable Salt)
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product uses a predictable salt as part of the input.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of RSA Algorithm without OAEP - (780)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 780 (Use of RSA Algorithm without OAEP)
The product uses the RSA algorithm but does not incorporate Optimal Asymmetric Encryption Padding (OAEP), which might weaken the encryption.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Insecure Storage of Sensitive Information - (922)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 922 (Insecure Storage of Sensitive Information)
The product stores sensitive information without properly limiting read or write access by unauthorized actors.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Identify Actors - (1014)
1008 (Architectural Concepts) > 1014 (Identify Actors)
Weaknesses in this category are related to the design and architecture of a system's identification management components. Frequently these deal with verifying that external agents provide inputs into the system. The weaknesses in this category could lead to a degradation of the quality of identification management if they are not addressed when designing or implementing a secure architecture.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Certificate Validation - (295)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 295 (Improper Certificate Validation)
The product does not validate, or incorrectly validates, a certificate.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Following of a Certificate's Chain of Trust - (296)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 296 (Improper Following of a Certificate's Chain of Trust)
The product does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Validation of Certificate with Host Mismatch - (297)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 297 (Improper Validation of Certificate with Host Mismatch)
The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Validation of Certificate Expiration - (298)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 298 (Improper Validation of Certificate Expiration)
A certificate expiration is not validated or is incorrectly validated, so trust may be assigned to certificates that have been abandoned due to age.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Check for Certificate Revocation - (299)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 299 (Improper Check for Certificate Revocation)
The product does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a certificate that has been compromised.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Insufficient Verification of Data Authenticity - (345)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 345 (Insufficient Verification of Data Authenticity)
The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Origin Validation Error - (346)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 346 (Origin Validation Error)
The product does not properly verify that the source of data or communication is valid.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Missing Check for Certificate Revocation after Initial Check - (370)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 370 (Missing Check for Certificate Revocation after Initial Check)
The product does not check the revocation status of a certificate after its initial revocation check, which can cause the product to perform privileged actions even after the certificate is revoked at a later time.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Unintended Proxy or Intermediary ('Confused Deputy') - (441)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 441 (Unintended Proxy or Intermediary ('Confused Deputy'))
The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Confused Deputy
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Missing Validation of OpenSSL Certificate - (599)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 599 (Missing Validation of OpenSSL Certificate)
The product uses OpenSSL and trusts or uses a certificate without using the SSL_get_verify_result() function to ensure that the certificate satisfies all necessary security requirements.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Verification of Source of a Communication Channel - (940)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 940 (Improper Verification of Source of a Communication Channel)
The product establishes a communication channel to handle an incoming request that has been initiated by an actor, but it does not properly verify that the request is coming from the expected origin.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incorrectly Specified Destination in a Communication Channel - (941)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 941 (Incorrectly Specified Destination in a Communication Channel)
The product creates a communication channel to initiate an outgoing request to an actor, but it does not correctly specify the intended destination for that actor.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Limit Access - (1015)
1008 (Architectural Concepts) > 1015 (Limit Access)
Weaknesses in this category are related to the design and architecture of system resources. Frequently these deal with restricting the amount of resources that are accessed by actors, such as memory, network connections, CPU or access points. The weaknesses in this category could lead to a degradation of the quality of authentication if they are not addressed when designing or implementing a secure architecture.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Insertion of Sensitive Information Into Sent Data - (201)
1008 (Architectural Concepts) > 1015 (Limit Access) > 201 (Insertion of Sensitive Information Into Sent Data)
The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Generation of Error Message Containing Sensitive Information - (209)
1008 (Architectural Concepts) > 1015 (Limit Access) > 209 (Generation of Error Message Containing Sensitive Information)
The product generates an error message that includes sensitive information about its environment, users, or associated data.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Removal of Sensitive Information Before Storage or Transfer - (212)
1008 (Architectural Concepts) > 1015 (Limit Access) > 212 (Improper Removal of Sensitive Information Before Storage or Transfer)
The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Creation of chroot Jail Without Changing Working Directory - (243)
1008 (Architectural Concepts) > 1015 (Limit Access) > 243 (Creation of chroot Jail Without Changing Working Directory)
The product uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Execution with Unnecessary Privileges - (250)
1008 (Architectural Concepts) > 1015 (Limit Access) > 250 (Execution with Unnecessary Privileges)
The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Externally Controlled Reference to a Resource in Another Sphere - (610)
1008 (Architectural Concepts) > 1015 (Limit Access) > 610 (Externally Controlled Reference to a Resource in Another Sphere)
The product uses an externally controlled name or reference that resolves to a resource that is outside of the intended control sphere.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Restriction of XML External Entity Reference - (611)
1008 (Architectural Concepts) > 1015 (Limit Access) > 611 (Improper Restriction of XML External Entity Reference)
The product processes an XML document that can contain XML entities with URIs that resolve to documents outside of the intended sphere of control, causing the product to embed incorrect documents into its output. XXE
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. External Control of File Name or Path - (73)
1008 (Architectural Concepts) > 1015 (Limit Access) > 73 (External Control of File Name or Path)
The product allows user input to control or influence paths or file names that are used in filesystem operations.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Limit Exposure - (1016)
1008 (Architectural Concepts) > 1016 (Limit Exposure)
Weaknesses in this category are related to the design and architecture of the entry points to a system. Frequently these deal with minimizing the attack surface through designing the system with the least needed amount of entry points. The weaknesses in this category could lead to a degradation of a system's defenses if they are not addressed when designing or implementing a secure architecture.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Self-generated Error Message Containing Sensitive Information - (210)
1008 (Architectural Concepts) > 1016 (Limit Exposure) > 210 (Self-generated Error Message Containing Sensitive Information)
The product identifies an error condition and creates its own diagnostic or error messages that contain sensitive information.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Externally-Generated Error Message Containing Sensitive Information - (211)
1008 (Architectural Concepts) > 1016 (Limit Exposure) > 211 (Externally-Generated Error Message Containing Sensitive Information)
The product performs an operation that triggers an external diagnostic or error message that is not directly generated or controlled by the product, such as an error generated by the programming language interpreter that a software application uses. The error can contain sensitive system information.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Invocation of Process Using Visible Sensitive Information - (214)
1008 (Architectural Concepts) > 1016 (Limit Exposure) > 214 (Invocation of Process Using Visible Sensitive Information)
A process is invoked with sensitive command-line arguments, environment variables, or other elements that can be seen by other processes on the operating system.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Server-generated Error Message Containing Sensitive Information - (550)
1008 (Architectural Concepts) > 1016 (Limit Exposure) > 550 (Server-generated Error Message Containing Sensitive Information)
Certain conditions, such as network failure, will cause a server error message to be displayed.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Inclusion of Functionality from Untrusted Control Sphere - (829)
1008 (Architectural Concepts) > 1016 (Limit Exposure) > 829 (Inclusion of Functionality from Untrusted Control Sphere)
The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Inclusion of Web Functionality from an Untrusted Source - (830)
1008 (Architectural Concepts) > 1016 (Limit Exposure) > 830 (Inclusion of Web Functionality from an Untrusted Source)
The product includes web functionality (such as a web widget) from another domain, which causes it to operate within the domain of the product, potentially granting total access and control of the product to the untrusted source.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Lock Computer - (1017)
1008 (Architectural Concepts) > 1017 (Lock Computer)
Weaknesses in this category are related to the design and architecture of a system's lockout mechanism. Frequently these deal with scenarios that take effect in case of multiple failed attempts to access a given resource. The weaknesses in this category could lead to a degradation of access to system assets if they are not addressed when designing or implementing a secure architecture.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Overly Restrictive Account Lockout Mechanism - (645)
1008 (Architectural Concepts) > 1017 (Lock Computer) > 645 (Overly Restrictive Account Lockout Mechanism)
The product contains an account lockout protection mechanism, but the mechanism is too restrictive and can be triggered too easily, which allows attackers to deny service to legitimate users by causing their accounts to be locked out.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Manage User Sessions - (1018)
1008 (Architectural Concepts) > 1018 (Manage User Sessions)
Weaknesses in this category are related to the design and architecture of session management. Frequently these deal with the information or status about each user and their access rights for the duration of multiple requests. The weaknesses in this category could lead to a degradation of the quality of session management if they are not addressed when designing or implementing a secure architecture.
* Composite 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. 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. Session Fixation - (384)
1008 (Architectural Concepts) > 1018 (Manage User Sessions) > 384 (Session Fixation)
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Data Element to Wrong Session - (488)
1008 (Architectural Concepts) > 1018 (Manage User Sessions) > 488 (Exposure of Data Element to Wrong Session)
The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. J2EE Bad Practices: Non-serializable Object Stored in Session - (579)
1008 (Architectural Concepts) > 1018 (Manage User Sessions) > 579 (J2EE Bad Practices: Non-serializable Object Stored in Session)
The product stores a non-serializable object as an HttpSession attribute, which can hurt reliability.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. J2EE Misconfiguration: Insufficient Session-ID Length - (6)
1008 (Architectural Concepts) > 1018 (Manage User Sessions) > 6 (J2EE Misconfiguration: Insufficient Session-ID Length)
The J2EE application is configured to use an insufficient session ID length.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Insufficient Session Expiration - (613)
1008 (Architectural Concepts) > 1018 (Manage User Sessions) > 613 (Insufficient Session Expiration)
According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Enforcement of Behavioral Workflow - (841)
1008 (Architectural Concepts) > 1018 (Manage User Sessions) > 841 (Improper Enforcement of Behavioral Workflow)
The product supports a session in which more than one behavior must be performed by an actor, but it does not properly ensure that the actor performs the behaviors in the required sequence.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Validate Inputs - (1019)
1008 (Architectural Concepts) > 1019 (Validate Inputs)
Weaknesses in this category are related to the design and architecture of a system's input validation components. Frequently these deal with sanitizing, neutralizing and validating any externally provided inputs to minimize malformed data from entering the system and preventing code injection in the input data. The weaknesses in this category could lead to a degradation of the quality of data flow in a system if they are not addressed when designing or implementing a secure architecture.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Neutralization of Special Elements - (138)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 138 (Improper Neutralization of Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as control elements or syntactic markers when they are sent to a downstream component.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Escape, Meta, or Control Sequences - (150)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 150 (Improper Neutralization of Escape, Meta, or Control Sequences)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Input Validation - (20)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 20 (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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Acceptance of Extraneous Untrusted Data With Trusted Data - (349)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 349 (Acceptance of Extraneous Untrusted Data With Trusted Data)
The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
* Composite 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. 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. Cross-Site Request Forgery (CSRF) - (352)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 352 (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. Session Riding Cross Site Reference Forgery XSRF
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. External Control of Assumed-Immutable Web Parameter - (472)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 472 (External Control of Assumed-Immutable Web Parameter)
The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields. Assumed-Immutable Parameter Tampering
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. PHP External Variable Modification - (473)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 473 (PHP External Variable Modification)
A PHP application does not properly protect against the modification of variables from external sources, such as query parameters or cookies. This can expose the application to numerous weaknesses that would not exist otherwise.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Deserialization of Untrusted Data - (502)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 502 (Deserialization of Untrusted Data)
The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid. Marshaling, Unmarshaling Pickling, Unpickling PHP Object Injection
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Link Resolution Before File Access ('Link Following') - (59)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 59 (Improper Link Resolution Before File Access ('Link Following'))
The product 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. insecure temporary file Zip Slip
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. URL Redirection to Untrusted Site ('Open Redirect') - (601)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 601 (URL Redirection to Untrusted Site ('Open Redirect'))
The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect. Open Redirect Cross-site Redirect Cross-domain Redirect Unvalidated Redirect
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Restriction of Names for Files and Other Resources - (641)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 641 (Improper Restriction of Names for Files and Other Resources)
The product constructs the name of a file or other resource using input from an upstream component, but it does not restrict or incorrectly restricts the resulting name.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Data within XPath Expressions ('XPath Injection') - (643)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 643 (Improper Neutralization of Data within XPath Expressions ('XPath Injection'))
The product uses external input to dynamically construct an XPath expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Data within XQuery Expressions ('XQuery Injection') - (652)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 652 (Improper Neutralization of Data within XQuery Expressions ('XQuery Injection'))
The product uses external input to dynamically construct an XQuery expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') - (74)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'))
The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Failure to Sanitize Special Elements into a Different Plane (Special Element Injection) - (75)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 75 (Failure to Sanitize Special Elements into a Different Plane (Special Element Injection))
The product does not adequately filter user-controlled input for special elements with control implications.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Equivalent Special Elements - (76)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 76 (Improper Neutralization of Equivalent Special Elements)
The product correctly neutralizes certain special elements, but it improperly neutralizes equivalent special elements.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Neutralization of Special Elements used in a Command ('Command Injection') - (77)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 77 (Improper Neutralization of Special Elements used in a Command ('Command Injection'))
The product constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component. Command injection
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Shell injection Shell metacharacters OS Command Injection
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - (79)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))
The product 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. XSS HTML Injection CSS
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Filtering of Special Elements - (790)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 790 (Improper Filtering of Special Elements)
The product receives data from an upstream component, but does not filter or incorrectly filters special elements before sending it to a downstream component.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Incomplete Filtering of Special Elements - (791)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 791 (Incomplete Filtering of Special Elements)
The product receives data from an upstream component, but does not completely filter special elements before sending it to a downstream component.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Incomplete Filtering of One or More Instances of Special Elements - (792)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 792 (Incomplete Filtering of One or More Instances of Special Elements)
The product receives data from an upstream component, but does not completely filter one or more instances of special elements before sending it to a downstream component.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Only Filtering One Instance of a Special Element - (793)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 793 (Only Filtering One Instance of a Special Element)
The product receives data from an upstream component, but only filters a single instance of a special element before sending it to a downstream component.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Incomplete Filtering of Multiple Instances of Special Elements - (794)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 794 (Incomplete Filtering of Multiple Instances of Special Elements)
The product receives data from an upstream component, but does not filter all instances of a special element before sending it to a downstream component.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Only Filtering Special Elements at a Specified Location - (795)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 795 (Only Filtering Special Elements at a Specified Location)
The product receives data from an upstream component, but only accounts for special elements at a specified location, thereby missing remaining special elements that may exist before sending it to a downstream component.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Only Filtering Special Elements Relative to a Marker - (796)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 796 (Only Filtering Special Elements Relative to a Marker)
The product receives data from an upstream component, but only accounts for special elements positioned relative to a marker (e.g. "at the beginning/end of a string; the second argument"), thereby missing remaining special elements that may exist before sending it to a downstream component.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Only Filtering Special Elements at an Absolute Position - (797)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 797 (Only Filtering Special Elements at an Absolute Position)
The product receives data from an upstream component, but only accounts for special elements at an absolute position (e.g. "byte number 10"), thereby missing remaining special elements that may exist before sending it to a downstream component.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') - (88)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 88 (Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))
The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - (89)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 89 (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'))
The product 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. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. SQL injection SQLi
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection') - (90)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 90 (Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection'))
The product constructs all or part of an LDAP query using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended LDAP query when it is sent to a downstream component.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. XML Injection (aka Blind XPath Injection) - (91)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 91 (XML Injection (aka Blind XPath Injection))
The product does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of CRLF Sequences ('CRLF Injection') - (93)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 93 (Improper Neutralization of CRLF Sequences ('CRLF Injection'))
The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Control of Generation of Code ('Code Injection') - (94)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 94 (Improper Control of Generation of Code ('Code Injection'))
The product 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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Neutralization of Special Elements in Data Query Logic - (943)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 943 (Improper Neutralization of Special Elements in Data Query Logic)
The product generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the intended logic of the query.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') - (95)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'))
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection') - (96)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 96 (Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection'))
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before inserting the input into an executable resource, such as a library, configuration file, or template.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Server-Side Includes (SSI) Within a Web Page - (97)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 97 (Improper Neutralization of Server-Side Includes (SSI) Within a Web Page)
The product generates a web page, but does not neutralize or incorrectly neutralizes user-controllable input that could be interpreted as a server-side include (SSI) directive.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') - (98)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 98 (Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion'))
The PHP application receives input from an upstream component, but it does not restrict or incorrectly restricts the input before its usage in "require," "include," or similar functions. Remote file include RFI Local file inclusion
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Control of Resource Identifiers ('Resource Injection') - (99)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 99 (Improper Control of Resource Identifiers ('Resource Injection'))
The product receives input from an upstream component, but it does not restrict or incorrectly restricts the input before it is used as an identifier for a resource that may be outside the intended sphere of control. Insecure Direct Object Reference
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Verify Message Integrity - (1020)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity)
Weaknesses in this category are related to the design and architecture of a system's data integrity components. Frequently these deal with ensuring integrity of data, such as messages, resource files, deployment files, and configuration files. The weaknesses in this category could lead to a degradation of data integrity quality if they are not addressed when designing or implementing a secure architecture.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Support for Integrity Check - (353)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 353 (Missing Support for Integrity Check)
The product uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Validation of Integrity Check Value - (354)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 354 (Improper Validation of Integrity Check Value)
The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Detection of Error Condition Without Action - (390)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 390 (Detection of Error Condition Without Action)
The product detects a specific error, but takes no actions to handle the error.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unchecked Error Condition - (391)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 391 (Unchecked Error Condition)
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Download of Code Without Integrity Check - (494)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 494 (Download of Code Without Integrity Check)
The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Reliance on Cookies without Validation and Integrity Checking - (565)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 565 (Reliance on Cookies without Validation and Integrity Checking)
The product relies on the existence or values of cookies when performing security-critical operations, but it does not properly ensure that the setting is valid for the associated user.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking - (649)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 649 (Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking)
The product uses obfuscation or encryption of inputs that should not be mutable by an external actor, but the product does not use integrity checks to detect if those inputs have been modified.
* Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. Improper Neutralization - (707)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 707 (Improper Neutralization)
The product does not ensure or incorrectly ensures that structured messages or data are well-formed and that certain security properties are met before being read from an upstream component or sent to a downstream component.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Handling of Exceptional Conditions - (755)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 755 (Improper Handling of Exceptional Conditions)
The product does not handle or incorrectly handles an exceptional condition.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Enforcement of Message Integrity During Transmission in a Communication Channel - (924)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 924 (Improper Enforcement of Message Integrity During Transmission in a Communication Channel)
The product establishes a communication channel with an endpoint and receives a message from that endpoint, but it does not sufficiently ensure that the message was not modified during transmission.
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: View

Rationale:

This entry is a View. Views are not weaknesses and therefore inappropriate to describe the root causes of vulnerabilities.

Comments:

Use this View or other Views to search and navigate for the appropriate weakness.
+ Notes

Other

The top level categories in this view represent the individual tactics that are part of a secure-by-design approach to software development. The weaknesses that are members of each category contain information about how each is introduced relative to the software's architecture. Three different modes of introduction are used: Omission - caused by missing a security tactic when it is necessary. Commission - refers to incorrect choice of tactics which could result in undesirable consequences. Realization - appropriate security tactics are adopted but are incorrectly implemented.
+ References
[REF-9] Santos, J. C. S., Tarrit, K. and Mirakhorli, M.. "A Catalog of Security Architecture Weaknesses.". 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/cawe-paper.pdf>.
[REF-10] Santos, J. C. S., Peruma, A., Mirakhorli, M., Galster, M. and Sejfia, A.. "Understanding Software Vulnerabilities Related to Architectural Security Tactics: An Empirical Investigation of Chromium, PHP and Thunderbird.". pages 69 - 78. 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/TacticalVulnerabilities.pdf>.
+ View Metrics
CWEs in this view Total CWEs
Weaknesses 223 out of 940
Categories 12 out of 374
Views 0 out of 51
Total 235 out of 1365
+ Content History
+ Submissions
Submission Date Submitter Organization
2017-06-22
(CWE 2.12, 2017-11-08)
Joanna C.S. Santos, Mehdi Mirakhorli
Provided the catalog, Common Architectural Weakness Enumeration (CAWE), and research papers for this view.
+ Modifications
Modification Date Modifier Organization
2018-03-27 CWE Content Team MITRE
updated Description, Other_Notes, View_Audience
2020-02-24 CWE Content Team MITRE
updated Maintenance_Notes, View_Audience
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

View Components

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data

Weakness ID: 349
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Access Control
Integrity

Technical Impact: Bypass Protection Mechanism; Modify Application Data

An attacker could package untrusted data with trusted data to bypass protection mechanisms to gain access to and possibly modify sensitive data.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 345 Insufficient Verification of Data Authenticity
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1214 Data Integrity Issues
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Observed Examples
Reference Description
Does not verify that trusted entity is authoritative for all entities in its response.
use of extra data in a signature allows certificate signature forging
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 860 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV)
MemberOf ViewView - 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). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 977 SFP Secondary Cluster: Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1150 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 16. Runtime Environment (ENV)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1365 ICS Communications: Unreliability
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1373 ICS Engineering (Construction/Deployment): Trust Model Problems
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1411 Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Untrusted Data Appended with Trusted Data
The CERT Oracle Secure Coding Standard for Java (2011) ENV01-J Place all security-sensitive code in a single JAR and sign and seal it
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2014-07-30 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2020-02-24 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Observed_Examples, Relationships
2022-04-28 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2023-04-27 CWE Content Team MITRE
updated Modes_of_Introduction, Relationships, Time_of_Introduction
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Untrusted Data Appended with Trusted Data

CWE-770: Allocation of Resources Without Limits or Throttling

Weakness ID: 770
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
+ Extended Description

Code frequently has to work with limited resources, so programmers must be careful to ensure that resources are not consumed too quickly, or too easily. Without use of quotas, resource limits, or other protection mechanisms, it can be easy for an attacker to consume many resources by rapidly making many requests, or causing larger resources to be used than is needed. When too many resources are allocated, or if a single resource is too large, then it can prevent the code from working correctly, possibly leading to a denial of service.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Availability

Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

When allocating resources without limits, an attacker could prevent other systems, applications, or processes from accessing the same type of resource.
+ Potential Mitigations

Phase: Requirements

Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.

Phase: Architecture and Design

Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

Phase: Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Note: This will only be applicable to cases where user input can influence the size or frequency of resource allocations.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Phase: Architecture and Design

Mitigation of resource exhaustion attacks requires that the target system either:

  • recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.

The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.

Phase: Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Phases: Architecture and Design; Implementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.

Ensure that all failures in resource allocation place the system into a safe posture.

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 400 Uncontrolled Resource Consumption
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 665 Improper Initialization
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 774 Allocation of File Descriptors or Handles Without Limits or Throttling
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 789 Memory Allocation with Excessive Size Value
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1325 Improperly Controlled Sequential Memory Allocation
CanFollow Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 20 Improper Input Validation
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 399 Resource Management Errors
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 840 Business Logic Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 400 Uncontrolled Resource Consumption
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation
System Configuration
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This code allocates a socket and forks each time it receives a new connection.

(bad code)
Example Language:
sock=socket(AF_INET, SOCK_STREAM, 0);
while (1) {
newsock=accept(sock, ...);
printf("A connection has been accepted\n");
pid = fork();
}

The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely.


Example 2

In the following example a server socket connection is used to accept a request to store data on the local file system using a specified filename. The method openSocketConnection establishes a server socket to accept requests from a client. When a client establishes a connection to this service the getNextMessage method is first used to retrieve from the socket the name of the file to store the data, the openFileToWrite method will validate the filename and open a file to write to on the local file system. The getNextMessage is then used within a while loop to continuously read data from the socket and output the data to the file until there is no longer any data from the socket.

(bad code)
Example Language:
int writeDataFromSocketToFile(char *host, int port)
{

char filename[FILENAME_SIZE];
char buffer[BUFFER_SIZE];
int socket = openSocketConnection(host, port);

if (socket < 0) {
printf("Unable to open socket connection");
return(FAIL);
}
if (getNextMessage(socket, filename, FILENAME_SIZE) > 0) {
if (openFileToWrite(filename) > 0) {
while (getNextMessage(socket, buffer, BUFFER_SIZE) > 0){
if (!(writeToFile(buffer) > 0))
break;
}
}
closeFile();
}
closeSocket(socket);
}

This example creates a situation where data can be dumped to a file on the local file system without any limits on the size of the file. This could potentially exhaust file or disk resources and/or limit other clients' ability to access the service.


Example 3

In the following example, the processMessage method receives a two dimensional character array containing the message to be processed. The two-dimensional character array contains the length of the message in the first character array and the message body in the second character array. The getMessageLength method retrieves the integer value of the length from the first character array. After validating that the message length is greater than zero, the body character array pointer points to the start of the second character array of the two-dimensional character array and memory is allocated for the new body character array.

(bad code)
Example Language:

/* process message accepts a two-dimensional character array of the form [length][body] containing the message to be processed */
int processMessage(char **message)
{
char *body;

int length = getMessageLength(message[0]);

if (length > 0) {
body = &message[1][0];
processMessageBody(body);
return(SUCCESS);
}
else {
printf("Unable to process message; invalid message length");
return(FAIL);
}
}

This example creates a situation where the length of the body character array can be very large and will consume excessive memory, exhausting system resources. This can be avoided by restricting the length of the second character array with a maximum length check

Also, consider changing the type from 'int' to 'unsigned int', so that you are always guaranteed that the number is positive. This might not be possible if the protocol specifically requires allowing negative values, or if you cannot control the return value from getMessageLength(), but it could simplify the check to ensure the input is positive, and eliminate other errors such as signed-to-unsigned conversion errors (CWE-195) that may occur elsewhere in the code.

(good code)
Example Language:
unsigned int length = getMessageLength(message[0]);
if ((length > 0) && (length < MAX_LENGTH)) {...}

Example 4

In the following example, a server object creates a server socket and accepts client connections to the socket. For every client connection to the socket a separate thread object is generated using the ClientSocketThread class that handles request made by the client through the socket.

(bad code)
Example Language: Java 
public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
t.start();
}
serverSocket.close();


} catch (IOException ex) {...}
}

In this example there is no limit to the number of client connections and client threads that are created. Allowing an unlimited number of client connections and threads could potentially overwhelm the system and system resources.

The server should limit the number of client connections and the client threads that are created. This can be easily done by creating a thread pool object that limits the number of threads that are generated.

(good code)
Example Language: Java 
public static final int SERVER_PORT = 4444;
public static final int MAX_CONNECTIONS = 10;
...

public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {
hasConnections = checkForMoreConnections();
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
ExecutorService pool = Executors.newFixedThreadPool(MAX_CONNECTIONS);
pool.execute(t);
}
serverSocket.close();


} catch (IOException ex) {...}
}

Example 5

An unnamed web site allowed a user to purchase tickets for an event. A menu option allowed the user to purchase up to 10 tickets, but the back end did not restrict the actual number of tickets that could be purchased.

Example 5 References:
[REF-667] Rafal Los. "Real-Life Example of a 'Business Logic Defect' (Screen Shots!)". 2011. <http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581>.

Example 6

Here the problem is that every time a connection is made, more memory is allocated. So if one just opened up more and more connections, eventually the machine would run out of memory.

(bad code)
Example Language:
bar connection() {
foo = malloc(1024);
return foo;
}

endConnection(bar foo) {
free(foo);
}

int main() {
while(1) {
foo=connection();
}

endConnection(foo)
}

+ Observed Examples
Reference Description
Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).
Language interpreter does not restrict the number of temporary files being created when handling a MIME request with a large number of parts..
Driver does not use a maximum width when invoking sscanf style functions, causing stack consumption.
Large integer value for a length property in an object causes a large amount of memory allocation.
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
Communication product allows memory consumption with a large number of SIP requests, which cause many sessions to be created.
Product allows attackers to cause a denial of service via a large number of directives, each of which opens a separate window.
CMS does not restrict the number of searches that can occur simultaneously, leading to resource exhaustion.
web application scanner attempts to read an excessively large file created by a user, causing process termination
Go-based workload orchestrator does not limit resource usage with unauthenticated connections, allowing a DoS by flooding the service
+ Detection Methods

Manual Static Analysis

Manual static analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. If denial-of-service is not considered a significant risk, or if there is strong emphasis on consequences such as code execution, then manual analysis may not focus on this weakness at all.

Fuzzing

While fuzzing is typically geared toward finding low-level implementation bugs, it can inadvertently find uncontrolled resource allocation problems. This can occur when the fuzzer generates a large number of test cases but does not restart the targeted product in between test cases. If an individual test case produces a crash, but it does not do so reliably, then an inability to limit resource allocation may be the cause.

When the allocation is directly affected by numeric inputs, then fuzzing may produce indications of this weakness.

Effectiveness: Opportunistic

Automated Dynamic Analysis

Certain automated dynamic analysis techniques may be effective in producing side effects of uncontrolled resource allocation problems, especially with resources such as processes, memory, and connections. The technique may involve generating a large number of requests to the product within a short time frame. Manual analysis is likely required to interpret the results.

Automated Static Analysis

Specialized configuration or tuning may be required to train automated tools to recognize this weakness.

Automated static analysis typically has limited utility in recognizing unlimited allocation problems, except for the missing release of program-independent system resources such as files, sockets, and processes, or unchecked arguments to memory. For system resources, automated static analysis may be able to detect circumstances in which resources are not released after they have expired, or if too much of a resource is requested at once, as can occur with memory. Automated analysis of configuration files may be able to detect settings that do not specify a maximum value.

Automated static analysis tools will not be appropriate for detecting exhaustion of custom resources, such as an intended security policy in which a bulletin board user is only allowed to make a limited number of posts per day.

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 802 2010 Top 25 - Risky Resource Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 857 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 858 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 861 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 867 2011 Top 25 - Weaknesses On the Cusp
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 876 CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 877 CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf ViewView - 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). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 985 SFP Secondary Cluster: Unrestricted Consumption
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1147 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1148 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1152 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

This entry is different from uncontrolled resource consumption (CWE-400) in that there are other weaknesses that are related to inability to control resource consumption, such as holding on to a resource too long after use, or not correctly keeping track of active resources so that they can be managed and released when they are finished (CWE-771).

Theoretical

Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011) FIO04-J Close resources when they are no longer needed
The CERT Oracle Secure Coding Standard for Java (2011) SER12-J Avoid memory and resource leaks during serialization
The CERT Oracle Secure Coding Standard for Java (2011) MSC05-J Do not exhaust heap space
ISA/IEC 62443 Part 4-2 Req CR 7.2
ISA/IEC 62443 Part 4-2 Req CR 2.7
ISA/IEC 62443 Part 4-1 Req SI-1
ISA/IEC 62443 Part 4-1 Req SI-2
ISA/IEC 62443 Part 3-3 Req SR 7.2
ISA/IEC 62443 Part 3-3 Req SR 2.7
+ References
[REF-386] Joao Antunes, Nuno Ferreira Neves and Paulo Verissimo. "Detection and Prediction of Resource-Exhaustion Vulnerabilities". Proceedings of the IEEE International Symposium on Software Reliability Engineering (ISSRE). 2008-11. <http://homepages.di.fc.ul.pt/~nuno/PAPERS/ISSRE08.pdf>.
[REF-387] D.J. Bernstein. "Resource exhaustion". <http://cr.yp.to/docs/resources.html>.
[REF-388] Pascal Meunier. "Resource exhaustion". Secure Programming Educational Material. 2004. <http://homes.cerias.purdue.edu/~pmeunier/secprog/sanitized/class1/6.resource%20exhaustion.ppt>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 17, "Protecting Against Denial of Service Attacks" Page 517. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-667] Rafal Los. "Real-Life Example of a 'Business Logic Defect' (Screen Shots!)". 2011. <http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581>.
[REF-672] Frank Kim. "Top 25 Series - Rank 22 - Allocation of Resources Without Limits or Throttling". SANS Software Security Institute. 2010-03-23. <https://web.archive.org/web/20170113055136/https://software-security.sans.org/blog/2010/03/23/top-25-series-rank-22-allocation-of-resources-without-limits-or-throttling/>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "Resource Limits", Page 574. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2009-05-13
(CWE 1.4, 2009-05-27)
CWE Content Team MITRE
+ Contributions
Contribution Date Contributor Organization
2023-11-14
(CWE 4.14, 2024-02-29)
participants in the CWE ICS/OT SIG 62443 Mapping Fall Workshop
Contributed or reviewed taxonomy mappings for ISA/IEC 62443
+ Modifications
Modification Date Modifier Organization
2009-07-27 CWE Content Team MITRE
updated Related_Attack_Patterns
2009-10-29 CWE Content Team MITRE
updated Relationships
2009-12-28 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Observed_Examples, References, Time_of_Introduction
2010-02-16 CWE Content Team MITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2010-04-05 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Related_Attack_Patterns
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples, Detection_Factors, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-02-18 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-06-23 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-07-30 CWE Content Team MITRE
updated Relationships
2015-12-07 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2018-03-27 CWE Content Team MITRE
updated References
2019-01-03 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2020-06-25 CWE Content Team MITRE
updated Applicable_Platforms, Description, Maintenance_Notes, Potential_Mitigations, Relationship_Notes, Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-07-20 CWE Content Team MITRE
updated Observed_Examples
2022-10-13 CWE Content Team MITRE
updated Observed_Examples, References
2023-01-31 CWE Content Team MITRE
updated Description, Detection_Factors
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Taxonomy_Mappings

CWE CATEGORY: Audit

Category ID: 1009
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the design and architecture of audit-based components of the system. Frequently these deal with logging user activities in order to identify attackers and modifications to the system. The weaknesses in this category could lead to a degradation of the quality of the audit capability if they are not addressed when designing or implementing a secure architecture.
+ Membership
Nature Type ID Name
MemberOf ViewView - 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). 1008 Architectural Concepts
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 117 Improper Output Neutralization for Logs
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 223 Omission of Security-relevant Information
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 224 Obscured Security-relevant Information by Alternate Name
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 532 Insertion of Sensitive Information into Log File
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 778 Insufficient Logging
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 779 Logging of Excessive Data
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ References
[REF-9] Santos, J. C. S., Tarrit, K. and Mirakhorli, M.. "A Catalog of Security Architecture Weaknesses.". 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/cawe-paper.pdf>.
[REF-10] Santos, J. C. S., Peruma, A., Mirakhorli, M., Galster, M. and Sejfia, A.. "Understanding Software Vulnerabilities Related to Architectural Security Tactics: An Empirical Investigation of Chromium, PHP and Thunderbird.". pages 69 - 78. 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/TacticalVulnerabilities.pdf>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2017-06-22
(CWE 2.12, 2017-11-08)
Joanna C.S. Santos, Mehdi Mirakhorli
Provided the catalog, Common Architectural Weakness Enumeration (CAWE), and research papers for this view.
+ Modifications
Modification Date Modifier Organization
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE CATEGORY: Authenticate Actors

Category ID: 1010
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the design and architecture of authentication components of the system. Frequently these deal with verifying the entity is indeed who it claims to be. The weaknesses in this category could lead to a degradation of the quality of authentication if they are not addressed when designing or implementing a secure architecture.
+ Membership
Nature Type ID Name
MemberOf ViewView - 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). 1008 Architectural Concepts
HasMember VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 258 Empty Password in Configuration File
HasMember VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 259 Use of Hard-coded Password
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 262 Not Using Password Aging
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 263 Password Aging with Long Expiration
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 287 Improper Authentication
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 288 Authentication Bypass Using an Alternate Path or Channel
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 289 Authentication Bypass by Alternate Name
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 290 Authentication Bypass by Spoofing
HasMember VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 291 Reliance on IP Address for Authentication
HasMember VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 293 Using Referer Field for Authentication
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 294 Authentication Bypass by Capture-replay
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 301 Reflection Attack in an Authentication Protocol
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 302 Authentication Bypass by Assumed-Immutable Data
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 303 Incorrect Implementation of Authentication Algorithm
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 304 Missing Critical Step in Authentication
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 305 Authentication Bypass by Primary Weakness
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 306 Missing Authentication for Critical Function
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 307 Improper Restriction of Excessive Authentication Attempts
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 308 Use of Single-factor Authentication
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 322 Key Exchange without Entity Authentication
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 521 Weak Password Requirements
HasMember VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 593 Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 603 Use of Client-Side Authentication
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 620 Unverified Password Change
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 640 Weak Password Recovery Mechanism for Forgotten Password
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 798 Use of Hard-coded Credentials
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 836 Use of Password Hash Instead of Password for Authentication
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 916 Use of Password Hash With Insufficient Computational Effort
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ References
[REF-9] Santos, J. C. S., Tarrit, K. and Mirakhorli, M.. "A Catalog of Security Architecture Weaknesses.". 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/cawe-paper.pdf>.
[REF-10] Santos, J. C. S., Peruma, A., Mirakhorli, M., Galster, M. and Sejfia, A.. "Understanding Software Vulnerabilities Related to Architectural Security Tactics: An Empirical Investigation of Chromium, PHP and Thunderbird.". pages 69 - 78. 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/TacticalVulnerabilities.pdf>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2017-06-22
(CWE 2.12, 2017-11-08)
Joanna C.S. Santos, Mehdi Mirakhorli
Provided the catalog, Common Architectural Weakness Enumeration (CAWE), and research papers for this view.
+ Modifications
Modification Date Modifier Organization
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE-289: Authentication Bypass by Alternate Name

Weakness ID: 289
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1390 Weak Authentication
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 46 Path Equivalence: 'filename ' (Trailing Space)
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 52 Path Equivalence: '/multiple/trailing/slash//'
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 173 Improper Handling of Alternate Encoding
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 178 Improper Handling of Case Sensitivity
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1211 Authentication Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Observed Examples
Reference Description
Protection mechanism that restricts URL access can be bypassed using URL encoding.
Bypass of authentication for files using "\" (backslash) or "%5C" (encoded backslash).
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 845 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 947 SFP Secondary Cluster: Authentication Bypass
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1134 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

Overlaps equivalent encodings, canonicalization, authorization, multiple trailing slash, trailing space, mixed case, and other equivalence issues.

Theoretical

Alternate names are useful in data driven manipulation attacks, not just for authentication.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Authentication bypass by alternate name
The CERT Oracle Secure Coding Standard for Java (2011) IDS01-J CWE More Specific Normalize strings before validating them
SEI CERT Oracle Coding Standard for Java IDS01-J CWE More Specific Normalize strings before validating them
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Description, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-11-24 CWE Content Team MITRE
updated Observed_Examples
2009-07-27 CWE Content Team MITRE
updated Other_Notes, Potential_Mitigations, Theoretical_Notes
2011-03-29 CWE Content Team MITRE
updated Potential_Mitigations
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-07-30 CWE Content Team MITRE
updated Relationships
2017-05-03 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2020-06-25 CWE Content Team MITRE
updated Potential_Mitigations
2022-10-13 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Type
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE-302: Authentication Bypass by Assumed-Immutable Data

Weakness ID: 302
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Potential Mitigations

Phases: Architecture and Design; Operation; Implementation

Implement proper protection for immutable data (e.g. environment variable, hidden form fields, etc.)
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 807 Reliance on Untrusted Inputs in a Security Decision
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1390 Weak Authentication
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

</