이 프로그램은 문자열이 같은지 비교하기 위해 == 또는 !=을 사용하는데 이 연산자는 두 개체의 값이 아닌 참조를 비교합니다. 두 참조가 같지 않을 가능성이 큽니다.

예제 1: 다음 분기는 실행되지 않습니다.

  if (args[0] == STRING_CONSTANT) {
      logger.info("miracle");
  }

== 및 != 연산자는 같은 개체에 포함된 문자열을 비교하도록 사용할 때에만 예상대로 작동합니다. 이를 위한 가장 일반적인 방법은 인턴(intern)된 문자열에 대한 것이고, 여기에서 이 문자열은 String 클래스에 의해 유지되는 개체의 풀에 추가할 수 있습니다. 한 번 문자열이 인턴(intern)되면, 모든 문자열 사용은 동일한 개체를 사용하고 같은 연산자가 예상대로 작동합니다. 모든 문자열 리터럴 및 문자열 값 상수는 자동으로 인턴(intern)됩니다. 다른 문자열은 String.intern()을 수동으로 호출하여 인턴할 수 있어 현재 문자열의 정규 인스턴스를 반환하고, 필요한 경우 하나를 생성합니다.

이 필드는 FortifyNonZero로 주석 추가되었으며 0은 허용된 값이 아님을 나타내는 데 사용됩니다.

정적 메서드는 클래스의 인스턴스가 아닌 클래스 자체에 속하므로 원칙적으로 오버라이드할 수 없습니다. 정적 메서드가 하위 클래스에서 오버라이드된 것처럼 표시되는 경우도 있는데, 이로 인해 혼동을 하여 잘못된 메서드 버전을 호출하게 될 수도 있습니다.

예제 1: 다음 코드는 사용자 인증을 위한 API를 정의합니다.

class AccessLevel{
  public static final int ROOT = 0;
  //...
  public static final int NONE = 9;
}
//...
class User {
  private static int access;
  public User(){
    access = AccessLevel.ROOT;
  }
  public static int getAccessLevel(){
    return access;
  }
  //...
}
class RegularUser extends User {
  private static int access;
  public RegularUser(){
    access = AccessLevel.NONE;
  }
  public static int getAccessLevel(){
    return access;
  }
  public static void escalatePrivilege(){
    access = AccessLevel.ROOT;
  }
  //...
}
//...
class SecureArea {
  //...
  public static void doRestrictedOperation(User user){
    if (user instanceof RegularUser){
      if (user.getAccessLevel() == AccessLevel.ROOT){
        System.out.println("doing a privileged operation");
      }else{
        throw new RuntimeException();
      }
    }
  }
}

이 코드는 처음 보기에는 아무 문제가 없는 것 같습니다. 그러나 User 또는 RegularUser 클래스가 아닌 user 인스턴스에 대해 getAccessLevel() 메서드를 호출하므로 이 조건에서는 항상 true가 반환됩니다. 그리고 이 if/else 블록 부분으로 진입하기 위해 instanceof를 사용했더라도 제한된 작업이 수행됩니다.

코드 정확성: serializable 클래스가 serialization 또는 deserialization 함수를 작성하지만 올바른 서명을 따르지 않는 경우 잘못된 Serializable 메서드 서명 이슈가 발생합니다.

  private void writeObject(java.io.ObjectOutputStream out) throws IOException;
  private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;
  private void readObjectNoData() throws ObjectStreamException;

serialization에 필요한 메서드 서명이 아닌 서명을 사용하는 경우 serialization/deserialization 중에 메서드가 호출되지 않게 될 수 있습니다. 그러면 serialization/deserialization이 완료되지 않거나, 신뢰할 수 없는 코드가 개체에 접근할 수 있습니다.
발생(throw)하지 않은 예외가 있는 경우 serialization/deserialization이 실패하여 응용 프로그램이 중단되거나 그러한 개체가 부분적으로만 올바르게 생성되었을 수 있습니다. 이로 인해 디버깅하기 매우 어려운 취약점이 발생할 수 있습니다. 호출자가 이러한 예외를 캐치(catch)해야 프로그램이 중단되거나 개체가 부분적으로 생성되는 일 없이 그러한 잘못된 serialization/deserialization이 적절하게 처리될 수 있습니다.

Java Object Serialization Specification을 사용하면 개발자는 serialPersistentFields 배열에서 지정하여 클래스에 대해 Serializable 필드를 수동으로 정의할 수 있습니다. 이 기능은 serialPersistentFields가 private, static 및 final로 선언된 경우에만 작동합니다.

예제 1: 다음 serialPersistentFields 선언은 private, static 및 final이 아니기 때문에 Serializable 필드를 정의하는 데 사용되지 않습니다.

class List implements Serializable {
public ObjectStreamField[] serialPersistentFields = { new ObjectStreamField("myField", List.class) };
...
}

대부분의 경우에는 배열에 대한 Object.equals() 호출은 잘못된 것입니다. 이와 같이 호출하면 배열 요소가 아니라 배열 주소가 같은지를 확인하기 때문입니다. 일반적으로는 java.util.Arrays.equals()를 대신 호출해야 합니다.

예제 1: 다음 코드에서는 Object.equals() 함수를 사용하여 두 배열 확인을 시도합니다.

...
  int[] arr1 = new int[10];
  int[] arr2 = new int[10];
  ...
  if (arr1.equals(arr2)){
    //treat arrays as if identical elements
  }
...

특정 지점에서 한 배열을 다른 배열에 할당하는 경우가 아니면 이러한 코드는 거의 항상 실행되지 않습니다.

이 메서드의 이름은 일반 Java 메서드 이름과 비슷하지만 철자가 틀렸거나 인수 목록이 의도한 메서드를 덮어쓰게 만듭니다.

예제 1: 다음 메서드는 Object.equals()를 오버라이드합니다.

public boolean equals(Object obj1, Object obj2) {
  ...
}

Object.equals()가 하나의 인수만 받기 때문에 Example 1의 메서드는 호출되지 않습니다.