CWE-1235: Incorrect Use of Autoboxing and Unboxing for Performance Critical Operations
The code uses boxed primitives, which may introduce inefficiencies into performance-critical operations.
Last updated
Overview
CWE-1235 (Incorrect Use of Autoboxing and Unboxing for Performance Critical Operations) is a base-level software weakness catalogued by MITRE in the Common Weakness Enumeration (CWE). It describes a recurring type of mistake that can lead to exploitable security vulnerabilities.
Background
Languages such as Java and C# support automatic conversion through their respective compilers from primitive types into objects of the corresponding wrapper classes, and vice versa. For example, a compiler might convert an int to Integer (called autoboxing) or an Integer to int (called unboxing). This eliminates forcing the programmer to perform these conversions manually, which makes the code cleaner.
Common consequences
What can happen when CWE-1235 is exploited.
DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory), DoS: Resource Consumption (Other), Reduce Performance
Affects: Availability
Incorrect autoboxing/unboxing would result in reduced performance, which sometimes can lead to resource consumption issues, impacting availability when used with generic collections.
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Languages
How to prevent it
Practical mitigations for CWE-1235, grouped by where in the lifecycle they apply.
Use of boxed primitives should be limited to certain situations such as when calling methods with typed parameters. They should not be used for scientific computing or other performance critical operations. They are only suited to support "impedance mismatch" between reference types and primitives. Examine the use of boxed primitives prior to use. Use SparseArrays or ArrayMap instead of HashMap to avoid performance overhead.
How to detect it
Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
Java has a boxed primitive for each primitive type. A long can be represented with the boxed primitive Long. Issues arise where boxed primitives are used when not strictly necessary.
Vulnerable example
Long count = 0L;In the above loop, we see that the count variable is declared as a boxed primitive. This causes autoboxing on the line that increments. This causes execution to be magnitudes less performant (time and possibly space) than if the "long" primitive was used to declare the count variable, which can impact availability of a resource.
This code uses primitive long which fixes the issue.
Safe example
long count = 0L;Terminology & mappings
Mapped taxonomies
- SEI CERT Oracle Coding Standard for Java: Do not pass arguments to certain Java Collections Framework methods that are a different type than the collection parameter type (EXP04-J)
- ISA/IEC 62443: Req SI-2 (Part 4-1)
Frequently asked questions
Common questions about CWE-1235.
- What is CWE-1235?
- The code uses boxed primitives, which may introduce inefficiencies into performance-critical operations.
- How do you prevent CWE-1235?
- Use of boxed primitives should be limited to certain situations such as when calling methods with typed parameters. They should not be used for scientific computing or other performance critical operations. They are only suited to support "impedance mismatch" between reference types and primitives. Examine the use of boxed primitives prior to use. Use SparseArrays or ArrayMap instead of HashMap to avoid performance overhead.
- How is CWE-1235 detected?
- Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
- What are the consequences of CWE-1235?
- Exploiting CWE-1235 can lead to: DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory), DoS: Resource Consumption (Other), Reduce Performance.
References
- MITRE CWE definition (CWE-1235) (opens in a new tab)
- CWE-1235 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-1235
Get alerted the moment a new CWE-1235 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.