Category: SFP Secondary Cluster: Use of an Improper API
Incomplete
Summary
This category identifies Software Fault Patterns (SFPs) within the Use of an Improper API cluster (SFP3).
Membership
| ID | Name | Description |
|---|---|---|
| CWE-111 | Direct Use of Unsafe JNI | This weakness occurs when a Java application directly calls native code through the Java Native Interface (JNI), exposing the entire application to security risks present in that external code, even if Java itself is safe from those specific flaws. |
| CWE-242 | Use of Inherently Dangerous Function | This vulnerability occurs when code uses functions that are inherently unsafe and cannot be reliably secured, posing a direct risk to application stability and security. |
| CWE-245 | J2EE Bad Practices: Direct Management of Connections | This vulnerability occurs when a J2EE application handles database connections directly instead of using the container's built-in connection management system. |
| CWE-246 | J2EE Bad Practices: Direct Use of Sockets | This vulnerability occurs when a J2EE application creates network sockets directly, bypassing the container-managed communication framework provided by the platform. |
| CWE-382 | J2EE Bad Practices: Use of System.exit() | This vulnerability occurs when a J2EE application directly calls System.exit(), which forcibly terminates the entire application server process, not just the application itself. |
| CWE-383 | J2EE Bad Practices: Direct Use of Threads | Creating or managing threads directly within a J2EE application is a risky practice that violates the platform's standards and often leads to unstable applications. |
| CWE-432 | Dangerous Signal Handler not Disabled During Sensitive Operations | This vulnerability occurs when a program's signal handler, which shares resources like global variables with other handlers, can be interrupted and re-entered before it finishes its work. The program fails to block other signals during this sensitive operation, leaving shared state vulnerable to corruption. |
| CWE-439 | Behavioral Change in New Version or Environment | This vulnerability occurs when a component's behavior unexpectedly changes after an update or when deployed to a different environment, and the systems or users depending on it are unaware of and cannot manage this change. |
| CWE-440 | Expected Behavior Violation | This weakness occurs when a software component, such as a function, API, or feature, fails to act as documented or intended. The system's actual behavior deviates from its promised specification, leading to unpredictable results. |
| CWE-474 | Use of Function with Inconsistent Implementations | This vulnerability occurs when code relies on a function whose behavior changes across different operating systems or versions, leading to unpredictable security risks when the software runs in an unexpected environment. |
| CWE-477 | Use of Obsolete Function | This vulnerability occurs when code relies on deprecated or obsolete functions, indicating outdated practices and insufficient maintenance that can introduce security gaps. |
| CWE-479 | Signal Handler Use of a Non-reentrant Function | This vulnerability occurs when a signal handler in your code calls a function that is not safe to re-enter. If that function is interrupted and called again before it finishes, it can corrupt memory and crash your program or create security weaknesses. |
| CWE-558 | Use of getlogin() in Multithreaded Application | Using the getlogin() function in a multithreaded application can lead to unreliable or incorrect username results, creating security and logic flaws. |
| CWE-572 | Call to Thread run() instead of start() | This vulnerability occurs when a program incorrectly calls a thread's `run()` method directly, instead of using the `start()` method. This mistake causes the thread's code to execute within the caller's current thread, bypassing the creation of a new, concurrent thread of execution. |
| CWE-573 | Improper Following of Specification by Caller | This weakness occurs when software fails to properly follow the documented rules, protocols, or requirements of an external component it uses, such as a library, API, framework, or platform. |
| CWE-574 | EJB Bad Practices: Use of Synchronization Primitives | This vulnerability occurs when an Enterprise JavaBeans (EJB) component improperly uses thread synchronization primitives, violating the EJB specification's design principles. |
| CWE-575 | EJB Bad Practices: Use of AWT Swing | This vulnerability occurs when an Enterprise JavaBeans (EJB) component incorrectly uses AWT or Swing UI toolkits, violating the EJB specification's design principles. |
| CWE-576 | EJB Bad Practices: Use of Java I/O | This vulnerability occurs when an Enterprise JavaBeans (EJB) component incorrectly uses Java I/O (java.io) operations to access the file system, violating the EJB specification's design principles. |
| CWE-577 | EJB Bad Practices: Use of Sockets | This vulnerability occurs when an Enterprise JavaBeans (EJB) component breaks the EJB specification by directly creating or using network sockets. |
| CWE-578 | EJB Bad Practices: Use of Class Loader | This vulnerability occurs when an Enterprise JavaBeans (EJB) component directly manipulates the Java class loader, violating the EJB specification's security and portability rules. |
| CWE-586 | Explicit Call to Finalize() | This vulnerability occurs when code directly calls an object's finalize() method from outside its designated finalizer context. |
| CWE-589 | Call to Non-ubiquitous API | This vulnerability occurs when software relies on an operating system function that isn't available on all versions of the target platform. This can cause crashes, unexpected behavior, or security failures when the software runs in an environment where the API is missing. |
| CWE-617 | Reachable Assertion | A reachable assertion occurs when an attacker can trigger an assert() statement or similar debugging check, causing the application to crash or behave in a more disruptive way than intended. This turns a helpful development tool into a denial-of-service vulnerability. |
| CWE-676 | Use of Potentially Dangerous Function | This vulnerability occurs when code calls a function that can be dangerous if misused, but can also be used safely with proper precautions. The risk lies not in the function itself, but in how it's implemented. |
| CWE-684 | Incorrect Provision of Specified Functionality | This weakness occurs when software behaves differently than its documented specifications, which can mislead users and create security risks. |
| CWE-695 | Use of Low-Level Functionality | This vulnerability occurs when code bypasses high-level framework controls by directly using low-level system functions, violating the intended security model. |
| CWE-758 | Reliance on Undefined, Unspecified, or Implementation-Defined Behavior | This weakness occurs when software depends on specific behaviors of an API, data structure, or system component that are not formally guaranteed by its specification. The code assumes these behaviors will always work a certain way, but they might change or fail under different conditions. |
| CWE-888 | Software Fault Pattern (SFP) Clusters | CWE identifiers in this view are associated with clusters of Software Fault Patterns (SFPs). |
| CWE-227 | 7PK - API Abuse | This category represents one of the phyla in the Seven Pernicious Kingdoms vulnerability classification. It includes weaknesses that involve the software using an API in a manner contrary to its intended use. According to the authors of the Seven Pernicious Kingdoms, "An API is a contract between a caller and a callee. The most common forms of API misuse occurs when the caller does not honor its end of this contract. For example, if a program does not call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller misuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated." |
Vulnerability Mapping Notes
Usage: Prohibited
Reasons: 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.
Comment:
See member weaknesses of this category.