Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (2.10)  

CWE-486: Comparison of Classes by Name

Weakness ID: 486
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

The program compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name.

Extended Description

If the decision to trust the methods and data of an object is based on the name of a class, it is possible for malicious users to send objects of the same name as trusted classes and thereby gain the trust afforded to known classes and types.

+ Time of Introduction
  • Implementation
+ Applicable Platforms



+ Common Consequences

Technical Impact: Execute unauthorized code or commands

If a program relies solely on the name of an object to determine identity, it may execute the incorrect or unintended code.

+ Likelihood of Exploit


+ Demonstrative Examples

Example 1

In this example, the expression in the if statement compares the class of the inputClass object to a trusted class by comparing the class names.

(Bad Code)
Example Language: Java 
if (inputClass.getClass().getName().equals("TrustedClassName")) {
// Do something assuming you trust inputClass
// ...

However, multiple classes can have the same name therefore comparing an object's class by name can allow untrusted classes of the same name as the trusted class to be use to execute unintended or incorrect code. To compare the class of an object to the intended class the getClass() method and the comparison operator "==" should be used to ensure the correct trusted class is used, as shown in the following example.

(Good Code)
Example Language: Java 
if (inputClass.getClass() == TrustedClass.class) {
// Do something assuming you trust inputClass
// ...

Example 2

In this example, the Java class, TrustedClass, overrides the equals method of the parent class Object to determine equivalence of objects of the class. The overridden equals method first determines if the object, obj, is the same class as the TrustedClass object and then compares the object's fields to determine if the objects are equivalent.

(Bad Code)
Example Language: Java 
public class TrustedClass {

public boolean equals(Object obj) {
boolean isEquals = false;

// first check to see if the object is of the same class
if (obj.getClass().getName().equals(this.getClass().getName())) {

// then compare object fields
if (...) {
isEquals = true;

return isEquals;


However, the equals method compares the class names of the object, obj, and the TrustedClass object to determine if they are the same class. As with the previous example using the name of the class to compare the class of objects can lead to the execution of unintended or incorrect code if the object passed to the equals method is of another class with the same name. To compare the class of an object to the intended class, the getClass() method and the comparison operator "==" should be used to ensure the correct trusted class is used, as shown in the following example.

(Good Code)
Example Language: Java 
public boolean equals(Object obj) {

// first check to see if the object is of the same class
if (obj.getClass() == this.getClass()) {

+ Potential Mitigations

Phase: Implementation

Use class equivalency to determine type. Rather than use the class name to determine if an object is of a given type, use the getClass() method, and == operator.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
Development Concepts699
ChildOfWeakness ClassWeakness Class485Insufficient Encapsulation
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
Research Concepts1000
ChildOfWeakness ClassWeakness Class697Insufficient Comparison
Research Concepts (primary)1000
ChildOfCategoryCategory849CERT Java Secure Coding Section 04 - Object Orientation (OBJ)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory998SFP Secondary Cluster: Glitch in Computation
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
PeerOfWeakness BaseWeakness Base386Symbolic Name not Mapping to Correct Object
Research Concepts1000
+ Relevant Properties
  • Equivalence
  • Uniqueness
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsComparing Classes by Name
CLASPComparing classes by name
CERT Java Secure CodingOBJ09-JCompare classes and not class names
Software Fault PatternsSFP1Glitch in computation
+ Content History
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Description, Relationships, Other_Notes, Relevant_Properties, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Other_Notes
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Comparing Classes by Name

More information is available — Please select a different filter.
Page Last Updated: January 18, 2017