黏性廣播的安全性無法透過權限來保護，因此任何接收者都可以存取。如果這些廣播包含敏感資料，或會傳送給惡意接收者，則可能會危害應用程式。

範例 1：以下程式碼傳送黏性廣播。

...
context.sendStickyBroadcast(intent);
...

更新 OS 後，對 android.permission 命名空間定義新的權限可能會產生預料之外的結果。若新版 OS 定義了完全相同的權限，Android Package Management Service (PMS) 會在不詢問使用者的情況下授予應用程式權限，這會導致權限提升攻擊。

由於此元件只預期從系統而非其他元件接收廣播訊息，它應該是私人的 (其他元件無法存取)。

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

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

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

範例 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：以下程式碼使用暫停按鈕以切換媒體播放。在使用者點選按鈕後，目前的歌曲或視訊便會停止，並釋放相機資源。但是，如果再次點選按鈕，則會在先前釋放的媒體資源上呼叫 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();
  }
  ...
}

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

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

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 檔案，就可以使用與原始應用程式相同的權限執行該動作。

Android 應用程式可設定為產生除錯二進位程式。這些二進位程式提供了詳細的除錯訊息，不應該在生產的環境中使用。<application> 標籤的 debuggable 屬性定義編譯後的二進位程式是否應包含除錯資訊。

使用除錯二進位程式會使應用程式提供許多有關其本身的資訊給使用者。除錯二進位程式只能用於開發或測試的環境中，如果將它們部署在生產的環境中，會有安全上的風險。攻擊者可能利用這些從除錯輸出得到的額外資訊，來發動針對架構、資料庫或應用程式所使用的其他資源的攻擊。

當惡意動作執行者可以在指定 Zip 檔案中指定 Zip 檔案項目名稱時，就會出現 Zip Path Traversal 弱點。當惡意指定 Zip 檔案項目名稱時，攻擊者可以在擴充對應的 Zip 檔案時覆寫關鍵系統檔案的內容。攻擊者可能會使用此類路徑穿越習慣用法 (例如 ../ 和 /) 來存取不在程式範圍內的系統檔案。依預設，瞄準 Android 14 及更高版本的 Android 應用程式可能會在 Zip 檔案解壓縮過程中偵測到 ../ 和 / 等習慣用法時法時拋出異常。此安全功能可以被覆寫或完全停用。

範例 1：以下程式碼將停用 Zip Entry Overwrite Protection。

...
dalvik.system.ZipPathValidator.clearCallback();
...

某些架構 (例如 AngularJS) 會限制可能針對其他網站和影像的連結設定的通訊協定。這主要是用來阻止內嵌 JavaScript 執行，可能會導致應用程式內出現其他 Cross-site scripting 弱點。

範例 1：以下內容將 AngularJS 中的預設通訊協定允許清單變更為同時允許影像 HTML 元素，從而允許內嵌 JavaScript。

myModule.config(function($compileProvider){
    $compileProvider.imgSrcSanitizationWhitelist(/^(http(s)?|javascript):.*/);
});

嚴格內容去除 (Strict Contextual Escaping，SCE) 是 AngularJS 應用程式中的一種機制，用於協助保護應用程式免於攻擊者的攻擊。這可以防止跨不同類型漏洞的許多攻擊途徑。其中最顯著的保護機制是防範特定類型的 Cross-site scripting 攻擊。在此應用程式中，此保護機制遭到明確停用。

範例 1：在此範例中，我們在模組上停用 SCE。

myModule.config(function($sceProvider){
  $sceProvider.enabled(false);
});

該應用程式使用啟用 Permessage-deflate WebSocket 擴充功能的程式碼，允許透過加密連線進行壓縮。啟用這種類型的壓縮後，會使應用程式可能遭受 CRIME 和 BREACH 類型的攻擊。

範例 1：以下程式碼將 DangerousEnableCompression 設定為 true，以啟用 'per-message-deflate' 擴充功能：

    app.Run(async context => {
        using var websocket = await context.WebSockets.AcceptWebSocketAsync(new WebSocketAcceptContext() { DangerousEnableCompression = true });
        await websocket.SendAsync(...);
        await websocket.ReceiveAsync(...);
        await websocket.CloseAsync(WebSocketCloseStatus.NormalClosure, null, default);
    });
    

範例 2：以下程式碼使用 DangerousDeflateOptions 設定 'per-message-deflate' 擴充功能的選項：

    using ClientWebSocket ws = new() {
        Options = {
            CollectHttpResponseDetails = true,
            DangerousDeflateOptions = new WebSocketDeflateOptions() {
                ClientMaxWindowBits = 10,
                ServerMaxWindowBits = 10
            }
        }
    };
    

根據預設，ASP.NET 伺服器會儲存 HttpSessionState 物件，以及在記憶體中它參照的屬性和任何物件。此模型會將作用中的階段作業狀態限制為，僅由單一機器的系統記憶體來提供。為了擴充這些限制的容量，要頻繁的配置伺服器以維持階段作業狀態資訊，如此不僅可擴充容量，還可在多台機器上進行複製以增進整體的效能。為了要維持其階段作業狀態，伺服器必須序列化 HttpSessionState 物件，此作業要求所有儲存在伺服器中的物件皆為可序列化的。

為了使階段作業能夠正確的進行序列化，所有應用程式儲存為階段作業屬性的物件必須聲明 [Serializable] 屬性。此外，如果物件要求自訂的序列化方法，它還必須執行 ISerializable 介面。

範例 1：以下的類別把自己新增至階段作業中，但因為它不可序列化，這個階段作業也就不能正確也序列化。

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

藉由縮小檔案大小進行精簡，可提升應用程式中有 JavaScript 檔案頁面的讀取時間。精簡表示移除非必要內容的程序，這些內容包括空白字元、註解、分號、括號、縮短本機變數的名稱及移除無法取得的程式碼。

範例 1：下列 ASPX 程式碼包含 Microsoft jQuery 程式庫的未精簡版本：

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

在 ASP.NET Web API 服務中，未經驗證的輸入是弱點產生的主因之一。未經檢查的輸入資料會導致許多弱點的產生，包括 Cross-Site Scripting、Process Control、Access Control 和 SQL injection。雖然 ASP.NET Web API 服務在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 ASP.NET Web API 服務呼叫未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 ASP.NET Web API 服務中利用輸入驗證弱點發起 Buffer overflow 攻擊。

若要防止此類攻擊：
1. 使用驗證屬性將針對參數或模型繫結物件參數之成員執行的驗證檢查，以程式化方式註解至 ASP.NET Web API 服務動作。
2. 使用 ModelState.IsValid 檢查模型是否通過驗證。

為了執行需特定權限的操作，Microsoft ASP.NET 應用程式能夠模擬目前使用者的安全環境或是模擬呼叫它們的程序。雖然模擬環境能夠提供多種用途 (例如減少必要 authentication 的數量)，但是擁有高度權限的程式會為整個系統的安全帶來不必要的危險。如果攻擊者利用程式中的另一個弱點，而此程式正在另一個安全環境中執行，則攻擊者能夠執行所有未授權的操作，並擁有與之對應的權限。

範例 1：以下程式碼範例說明使用 WindowsIdentity.Impersonate() 方法模擬憑證的典型方式。

using System.Security.Principal;
...

//Get the identity of the current user
IIdentity contextId = HttpContext.Current.User.Identity;
WindowsIdentity userId = (WindowsIdentity)contextId;

//Temporarily impersonate
WindowsImpersonationContext imp = userId.Impersonate();

//Perform tasks using the caller's security context
DoSecuritySensitiveTasks();

//Clean up and restore our old security context
impersonate.Undo();

Example 1 中的程式碼模擬目前使用者的安全環境，並使用此安全環境執行一個需權限的操作。呼叫 DoSecuritySensitiveTasks() 之後，程式碼企圖還原原始的安全環境，但是如果 DoSecuritySensitiveTasks() 拋出一個異常狀況，將永遠不會呼叫 Undo() 方法，而程式也將持續使用模擬的安全環境。

未依正確順序新增到中介軟體管道的 ASP.NET Core 中介軟體將無法依預期般執行，進而使應用程式可能面臨各種安全問題。

範例 1：UseCookiePolicy() 方法將 Cookie 原則中介軟體新增到中介軟體管道，進而允許自訂 Cookie 原則。當以錯誤的順序指定時，程式設計師聲明的任何 Cookie 原則將被忽略。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...