根據 RFC 2109，Cookie 嚴格意義上來說是 HTTP 機制。 不應合理預期 Cookie 適用於除 HTTP 以外的通訊協定，包括 file://。 目前尚不確定其行為，以及應套用哪些安全性劃分規則。 例如，從網際網路下載到本機磁碟的 HTML 檔案是否應該與本機安裝的任何 HTML 程式碼共用相同的 Cookie？

不建議開發人員使用未記錄或隱藏的 API 建置其應用程式。 無法保證 Google 在將來不會移除或變更這些 API，因此應加以避免，採用此類方法或欄位有很高的風險性，可能中斷您對應用程式的使用。

程式碼嘗試在 Camera 物件被解除之後，使用該物件。若在未重新要求 Camera 物件的情況下參照該資源，便會拋出異常，並在未能捕捉異常時造成應用程式當機。

範例：以下程式碼使用了切換按鈕以開關相機預覽。在使用者點選按鈕後，相機預覽便會停止，並解除相機資源。但是，如果再次點選按鈕，則會在先前解除的 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;
      }
  }
  ...
}

程式碼嘗試在媒體物件被解除之後使用該物件。若在未重新要求媒體物件的情況下參照該資源，便會拋出異常，並在未能捕捉異常時造成應用程式當機。

範例：以下程式碼使用了暫停按鈕以切換媒體播放。在使用者點選按鈕後，目前的歌曲或視訊便會停止，並解除相機資源。但是，如果再次點選按鈕，則會在先前解除的媒體物件上呼叫 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 資料庫處理常式已被解除後使用該處理常式。若在未重新建立資料庫連線的情況下參照該處理常式，便會拋出異常，並在未能捕捉異常時造成應用程式當機。

範例：以下程式碼可能是來自將使用者值暫時快取於記憶體中，但可以呼叫 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();
  }
  ...
}

硬體和裝置專用識別碼在資料掃除和原廠重設後仍然存在。我們不應該依靠這些識別碼來產生用來授權或驗證使用者的唯一識別碼。

此外，通用唯一識別碼可能與個人資訊有關連性，因此洩漏通用唯一識別碼會對使用者隱私和安全性造成威脅。

Android Class Loading Hijacking 弱點有以下兩種形式：

- 攻擊者可以變更程式為載入類別而搜尋的目錄名稱，從而指向處於其控制下之某個目錄的路徑：攻擊者明確控制應該從其中搜尋類別的路徑。

- 攻擊者可以篡改載入類別的環境：攻擊者間接控制路徑名稱代表的意義。

在此案例中，我們著重於第一種情況，即攻擊者可以控制為要載入之類別而搜尋的目錄的可能性。在以下情況下，會發生此類型的 Android Class Loading Hijacking 弱點：

1. 資料從不可信賴的來源進入應用程式。



2. 資料用作代表程式庫目錄的整個字串或一部分字串，以便搜尋要載入的類別。



3. 藉由從程式庫路徑執行程式碼，應用程式會給予攻擊者不應該擁有的權限或能力。

範例 1：以下程式碼使用使用者可變更的 userClassPath 來決定搜尋要載入的類別所在的目錄。

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

此程式碼能夠透過修改 userClassPath 的結果來指向所控制的其他路徑，從而讓攻擊者利用應用程式的提升權限，載入程式庫並潛在地執行任意程式碼。因為程式不會驗證從環境讀取的值，所以如果攻擊者可以控制 userClassPath 的值，則攻擊者便可使用與原始應用程式相同的權限，愚弄應用程式，讓應用程式指向他們所控制的目錄，從而載入他們所定義的類別。

範例 2：以下程式碼使用使用者可變更的 userOutput 來決定應寫入最佳化 DEX 檔案的目錄。

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

此程式碼可讓攻擊者指定最佳化 DEX 檔案 (ODEX) 的輸出目錄。然後，此程式碼還會讓惡意使用者將 userOutput 值變更為他們所控制的目錄，如外部儲存裝置。一旦完成竄改，便只需將輸出的 ODEX 檔案替換為惡意 ODEX 檔案，就可以使用與原始應用程式相同的權限執行該動作。