開発者がドキュメントに記載されていない、または非表示の API を使用してアプリケーションを構築することはお勧めしません。 Google がこれらの API を今後削除または変更しないという保証がないため、使用を避ける必要があります。そのようなメソッドやフィールドを使用すると、アプリケーションが破壊されるリスクが高くなります。

このコードは、Camera オブジェクトがすでに解放された後でこのオブジェクトの使用を試みます。リソースを再取得しないまま Camera オブジェクトをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、トグル ボタンを使用してカメラのプレビューをオン/オフしています。ユーザーがこのボタンを 1 度押すと、カメラのプレビューは停止し、カメラのリソースは解放されます。ただし、再びボタンを押すと、以前に解放された Camera オブジェクトで startPreview() がコールされます。

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

このコードは、メディアオブジェクトがすでに解放された後でこのオブジェクトの使用を試みます。リソースを再取得しないままこのメディアオブジェクトをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、一時停止ボタンを使用してメディアの再生を切り替えています。ユーザーがこのボタンを 1 度押すと、楽曲または動画の再生が一時停止し、カメラ リソースは解放されます。ただし、再びボタンを押すと、以前に解放されたメディア リソースで start() がコールされます。

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

このコードは、Android SQLite データベースハンドラがすでに閉じられた後でこのオブジェクトの使用を試みます。データベース接続を再確立しないままハンドラをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、ユーザー値を一時的にメモリにキャッシュするプログラムの一部だと考えられますが、ディスクへの変更をコミットするために flushUpdates() をコールすることができます。このメソッドは、データベースに更新を書き込んだ後、データベース ハンドラを適切に閉じます。しかし、再び flushUpdates() がコールされると、再初期化の前にデータベース オブジェクトが再び参照されます。

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

縮小化によってファイルサイズが減少するため、JavaScript ファイルを含むアプリケーションのページロード回数が向上します。縮小化とは、不用な空白、コメント、セミコロン、カッコを削除して、ローカル変数の名前を短縮し、使用しないコードを削除するプロセスです。

例 1: 次の ASPX コードには、Microsoft の jQuery ライブラリの縮小されていないバージョンが含まれています。

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

ブール値に対する算術演算子の動作は、整数値に対する動作とは異なるため、予期せぬ動作を引き起こす場合があります。

バイト配列からのデータが String に変換された場合、適用可能な文字セットに含まれないデータに何が起こるかは不明です。これによって、データが失われる可能性があります。また、適切なセキュリティ体制を保証するためにバイナリ データが必要な場合は、セキュリティ レベルの低下につながります。

例 1: 次のコードは、ハッシュを生成するためにデータを文字列に変換します。

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

ファイルのサイズが BUFSIZE より小さいと仮定すると、myFile の情報がデフォルトの文字セットと同様にエンコードされている限り問題はありません。ただし、別のエンコーディングが使用されていたり、ファイルがバイナリ ファイルである場合は、情報を失います。その結果、生成された SHA ハッシュの信頼性が損なわれ、特にデフォルトの文字セットに含まれないデータが疑問符などの同じ値で表されている場合、衝突が発生しやすくなった可能性があることを意味します。

notify() のコールで、起動されるスレッドを指定する方法はありません。

例 1: 次のコードでは、notifyJob() が notify() をコールします。

public synchronized notifyJob() {
flag = true;
notify();
}
...
public synchronized waitForSomething() {
while(!flag) {
    try {
        wait();
    }
    catch (InterruptedException e)
    {
        ...
    }
}
...
}

この場合、開発者はwait()をコールするスレッドを起動しようとしていますが、notify()が意図しているスレッドとは別のスレッドを通知する可能性があります。

ほとんどの場合、Thread オブジェクトの run() メソッドの直接コールはバグです。プログラマは制御の新規スレッドを開始しようとして、誤って start() の代わりに run() をコールしたため、run() メソッドがコーラーの支配下のスレッドで実行されます。

例 1: 次の Java プログラムからの抜粋は、start() の代わりに誤って run() をコールしています。

    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };

  thr.run();

ほとんどの場合、Thread オブジェクトの stop() メソッドの直接コールはバグです。プログラマーはスレッドの実行を中止しようとするかもしれませんが、スレッドの停止は適切な方法ではありません。Thread の stop() 関数は ThreadDeath 例外を Thread オブジェクトのどこかで引き起こす可能性があり、オブジェクトは不整合な状態になり、漏えいの可能性のあるリソースになります。API は本質的に安全ではないため、かなり前に廃止されています。

例 1: 次の例は、誤って Thread.stop() をコールしている Java プログラムです。

  ...
  public static void main(String[] args){
    ...
    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };
    ...
    thr.start();
    ...
    thr.stop();
    ...
  }

clone() と名付けられたメソッドを実装するため、プログラマはこのクラスで Cloneable インターフェイスの実装を意図したようです。しかし、クラスは Cloneable インターフェイスを実装せず、clone() メソッドは正しく動作しません。

例 1: このクラスに clone() をコールすると、結果として CloneNotSupportedException. になります。

public class Kibitzer {
  public Object clone() throws CloneNotSupportedException {
    ...
  }
}

ICloneable インターフェイスでは、ディープコピーが保証されず、このインターフェイスを実装するクラスはクローンが作成されるときに予想される通りに動作しない可能性があります。ICloneable を実装し、シャローコピー (別のオブジェクトへの既存の参照を含む、オブジェクトのみをコピーする方法) のみを行うクラスでは、予期せぬ動作が発生する可能性があります。ディープコピー (オブジェクトとすべての参照オブジェクトをコピーする方法) が一般にクローンメソッドの動作として仮定されているため、ICloneable インターフェイスを使用するとエラーが発生しやすくなります。このインターフェイスの使用は避ける必要があります。

clone() 関数がオーバーライド関数をコールする場合、クローンが部分的に初期化された状態で、あるいは壊れた状態で残ることがあります。

例 1: 次の clone() 関数は、オーバーライドされる可能性のあるメソッドをコールしています。

  ...
  class User implements Cloneable {
    private String username;
    private boolean valid;
    public Object clone() throws CloneNotSupportedException {
      final User clone = (User) super.clone();
      clone.doSomething();
      return clone;
    }
    public void doSomething(){
      ...
    }
  }

関数 doSomething() と括弧で囲まれたクラスは final ではないため、関数がオーバーライドされる可能性があります。その結果、クローン オブジェクト clone が部分的に初期化された状態で残され、ロジックを対処しなかった場合、予期しない方法でエラーが起こる可能性があります。

ボクシングされたプリミティブ型が等価かどうかを比較する場合、演算子 == や != ではなくボクシングされたプリミティブ型の equals() メソッドをコールするべきです。Java 仕様は、ボクシング変換について次のように記述しています。

"ボクシング変換の対象となる値 p が -128 から 127 までの数値であるint 型の整数リテラル、true または false のブール リテラル、「\u0000」から「\u007f」までの文字リテラルである場合、p に対する任意の 2 つのボクシング変換結果を a と b とする。この場合、常に a == b が成立する。"

これは、ボクシングされたプリミティブ型が使用される場合 (Boolean または Byte 以外)、特定の範囲の値のみがキャッシュまたはメモリに保存されることを意味します。値のサブセットでは、== または != を使用して正しい値を返します。このサブセットに含まれないすべての値では、オブジェクト アドレスを比較した結果を返します。

例 1: 次の例では、ボクシングされたプリミティブ型で等価演算子を使用しています。

  ...
  Integer mask0 = 100;
  Integer mask1 = 100;
  ...
  if (file0.readWriteAllPerms){
    mask0 = 777;
  }
  if (file1.readWriteAllPerms){
    mask1 = 777;
  }
  ...
  if (mask0 == mask1){
    //assume file0 and file1 have same permissions
    ...
  }
  ...

Example 1 のコードでは、Integer のボクシングされたプリミティブ型を使用して、2 つの int 値を比較しようとしています。mask0 と mask1 が両方とも 100 と等しい場合は、mask0 == mask1 は true を返します。しかし、mask0 と mask1 が両方とも 777 に等しい場合は、これらの値がボクシングされたプリミティブ型のキャッシュされた値の範囲内にないため、mask0 == maske1 は false を返します。

NaN と比較した場合、常に false と評価されます。例外は != 演算子で、NaN は非順序型であるため常に true と評価されます。

例 1: 次では、変数が NaN ではないことを確認しています。

  ...
  if (result == Double.NaN){
    //something went wrong
    throw new RuntimeException("Something went wrong, NaN found");
  }
  ...

ここでは、result が NaN ではないことの検証を試みています。しかし、NaN に演算子 == を使用すると、常に結果は false の値になり、このチェックで例外がスローされることはありません。

コンストラクターがオーバーライド可能な関数をコールするとき、オブジェクトが完全に初期化される前に攻撃者が this 参照にアクセスすることを許可する可能性があるため、脆弱性につながります。

例 1: 次の例では、オーバーライドされる可能性のあるメソッドをコールしています。

  ...
  class User {
    private String username;
    private boolean valid;
    public User(String username, String password){
      this.username = username;
      this.valid = validateUser(username, password);
    }
    public boolean validateUser(String username, String password){
      //validate user is real and can authenticate
      ...
    }
    public final boolean isValid(){
      return valid;
    }
  }

関数 validateUser とクラスは final ではないため、オーバーライドされる可能性があります。また、この関数をオーバーライドするサブクラスへの変数を初期化することで、validateUser 関数の回避を可能にしてしまいます。例：

  ...
  class Attacker extends User{
    public Attacker(String username, String password){
      super(username, password);
    }
    public boolean validateUser(String username, String password){
      return true;
    }
  }
  ...
  class MainClass{
    public static void main(String[] args){
      User hacker = new Attacker("Evil", "Hacker");
      if (hacker.isValid()){
        System.out.println("Attack successful!");
      }else{
        System.out.println("Attack failed");
      }
    }
  }

Example 1 のコードは "Attack successful!" を出力します。これは、Attacker クラスがスーパークラス User のコンストラクターからコールされる validateUser() 関数をオーバーライドすることで、Java は最初にコンストラクターからコールされた関数のサブクラスを見るためです。

攻撃者は、プログラムで悪意あるコードが実行されるようにするために、クラス名を故意に複製する可能性があります。この理由から、クラス名はタイプを表す識別子として適切ではないため、特定のオブジェクトを信頼する基準として使用しないでください。

例 1: 次のコードは、そのクラス名を基準にして inputReader オブジェクトからの入力を信頼するかどうかを決定しています。攻撃者が悪意あるコマンドを実行する inputReader の実装を提供できる場合、このコードはオブジェクトが無害であるか悪意あるものであるかを区別することができなくなります。

if (inputReader.getClass().getName().equals("com.example.TrustedClass")) {
   input = inputReader.getInput();
   ...
}

このフィールドには FortifyNonNegative というアノテーションが付けられています。これは、負の値が認められていないことを示すためのものです。

PL/SQL では、NULL の値は確定できません。どのような値とも等しくならず、別の NULL 値と同じになることもありません。また、null 値が他の値と同じになることはありません。

例 1: 以下のステートメントは必ず false になります。

checkNull BOOLEAN := x = NULL;

例 2: 以下のステートメントは必ず false になります。

checkNotNull BOOLEAN := x != NULL;

このプログラムは 2 つの文字列の比較に == または != を使用し、2 つのオブジェクトの値ではなく、オブジェクトが等価かどうかを比較します。このような場合、2 つの参照が等価でない可能性が高いのです。

例 1: 以下の分岐を通ることはありません。

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

== および != 演算子は、等価であるオブジェクトに含まれる文字列を比較するために使用されるときにのみ、予期されるとおりに動作します。これが発生する一般的な状況は、文字列が抑留され、String クラスにより保持されるオブジェクトのプールにこの文字列が追加される場合です。文字列が一度抑留されると、同じオブジェクトと等価演算子を使用する文字列のすべての使用は、予期されるとおりに動作します。すべての文字列リテラルおよび文字列値の定数は、自動的に抑留されます。その他の文字列は String.intern() を呼び出して手動で抑留できます。これにより、現在の文字列の正準な (規則に沿った) インスタンスが返されます (必要な場合には、正準なインスタンスが作成されます)。