多數應用程式使用 Cookie 來傳輸使用者的工作階段識別碼。當透過 HTTPS 存取應用程式時，Cookie 會受到保護 (攻擊者無法攔截 Cookie)。但是若開發人員允許透過 HTTP 存取非敏感的應用程式部份，則工作階段識別碼可能會遭竊取。當使用者瀏覽未受保護的網站部份，便會毫無掩飾的傳送包含工作階段 ID 的 Cookie。若攻擊者攔截網路資料，他們便可看見工作階段 ID 並將其用來控制使用者的工作階段。


以下範例將顯示結合不安全及安全通道的組態：

  <property name="filterInvocationDefinitionSource">
    <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      \A/secure/.*\Z=REQUIRES_SECURE_CHANNEL
      \A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
      \A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
      \A.*\Z=REQUIRES_INSECURE_CHANNEL
    </value>
  </property>

Acegi Security 允許在安全物件收回 (callback) 階段暫時替換 SecurityContext 中的 Authentication 物件。僅當 AuthenticationManager 和 AccessDecisionManager 成功處理原始 Authentication 物件時，此情形才會發生。RunAsManager 會建立此項 Authentication 物件。
通常開發人員會使用 RunAsManager，在方法叫用期間內替驗證的使用者設定一個或多個額外角色。這對須要存取遠端應用程式的安全 bean 很有幫助。由於遠端應用程式可能會要求不同的憑證，因此這可讓呼叫角色與遠端應用程式所需的角色之間進行轉譯，進而使遠端存取成功。系統將完全接受新的 Authentication 物件 (稱為 RunAsUserToken) 做為有效的 Authentication 物件，而不需任何進一步的 Authentication 或授權檢查。
將新的角色或權限新增至新的 Authentication 物件，可能會暫時提升使用者的權限，讓使用者進行未授權的行動。
以下組態顯示使用 RunAsManager，將「UBER_BOSS」角色新增至角色為「ROLE_PEON」的使用者，因此暫時將該名使用者提昇至管理員權限，這會讓所有未賦予權限的使用者取得 PrivateCatalog 的資料。

<bean id="bankManagerSecurity" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
...
 <property name="objectDefinitionSource">
   <value>
     com.example.service.PrivateCatalog.getData=ROLE_PEON,RUN_AS_UBER_BOSS
...
   </value>
 </property>
</bean>

雖然針對內容提供者定義單獨的讀取和寫入權限是個好方法，但是只定義 writePermission 可能會造成誤導。因為 SQL 的本質，產生純粹僅限寫入的查詢通常是不可能的：即使使用者無法直接存取資料，攻擊者還是可能透過操縱 where 子句來重建儲存的資料。

範例 1：以下是宣告只具有 writePermission 的內容提供者範例。

 <provider android:name=".ContentProvider" android:writePermission="content.permission.WRITE_CONTENT"/> 

沒有註冊廣播者權限的接收者會從任何廣播者接收訊息。如果這些訊息包含惡意資料，或來自惡意的廣播者，則可能會危害應用程式。

範例 1：以下程式碼在沒有指定廣播者權限的情況下註冊接收者。

...
context.registerReceiver(broadcastReceiver, intentFilter);
...

任何應用程式都可以存取未在其資料清單定義中明確指定存取權限的公用元件。

Android 應用程式中的活動、接收者和服務元件的 exported 屬性預設值會因是否有無 intent-filter 而有所不同。有 intent-filter 暗示該元件供外部使用，因此將 exported 屬性設定為 true。現在 Android 平台上的任何其他應用程式都可以存取此元件。

範例 1：以下是一個範例，說明有 intent-filter 且未明確設定存取權限的 Android 活動。

 <activity android:name=".AndroidActivity"/> 

   <intent-filter android:label="activityName"/> 

    <action android:name=".someFunAction"/> 

   </intent-filter> 

    ... 

 </activity> 

此活動可能被惡意應用程式所利用。

任何應用程式都可以存取未在其資料清單定義中明確指定存取權限的公用元件。將 android:minSdkVersion 或 android:targetSdkVersion 設為「16」或更低數值的應用程式，依系統預設會將 Android 內容提供者匯出。將這些屬性設為「17」或更高的應用程式，預設為「false」。

範例 1：以下是 Android 內容提供者宣告無明確存取權限或匯出旗標的範例。

 <provider android:name=".ContentProvider"/> 

Android 依賴安全性提供者來提供安全的網路通訊。但是，有時會在預設安全性提供者中發現弱點。為了防範這些弱點，Google Play 服務提供自動更新裝置安全性提供者的方式來抵禦已知的惡意探索。透過呼叫 Google Play 服務方法，您的應用程式可確保執行所在的裝置能夠擁有最新的更新來抵禦已知的惡意探索。

網路安全性組態功能可讓應用程式在安全的宣告式組態設定檔案中自訂其網路安全性設定，而不修改應用程式程式碼。這些設定可設定用於特定網域和特定應用程式。此功能的主要功能如下所示：
- 自訂信賴起點：自訂信任哪些憑證授權單位 (CA) 的應用程式安全連線。例如，信任特定的自行簽署憑證或限制該應用程式信任的一組公用 CA。
- 僅除錯覆寫：安全地除錯應用程式中的安全連線，而不向已安裝基準中新增風險。
- 純文字流量退出：保護應用程式，免於意外使用純文字流量。
- 憑證釘選：將應用程式的安全連線限制為特定憑證。

在沒有接收者權限的情況下所傳送的廣播可以被任何接收者存取。如果這些廣播包含敏感資料，或會傳送給惡意接收者，則可能會危害應用程式。

範例 1：以下程式碼在沒有指定接收者權限的情況下傳送廣播。

...
context.sendBroadcast(intent);
...

系統廣播可以傳送到私人元件。元件必須設為公開，才能接收來自第三方的非系統廣播。若在單一元件中註冊接收系統與非系統廣播，該元件 (系統部分) 的部分功能將對第三方公開，是沒有必要的。

宣告自訂權限時，有四個選項可用於指定權限的保護層級：normal、dangerous、signature 和 signature or system。Normal 權限會授予任何要求這些權限的應用程式。Dangerous 權限只會在使用者確認之後授予。Signature 權限只會授予由相同開發人員金鑰 (做為定義權限的封包) 所簽署的應用程式。Signature or system 權限與 signature 權限類似，但另外會被授予 Android 系統映像中的套件權限。

範例 1：以下是宣告具有 normal 保護層級的自訂權限範例。

 <permission android:name="custom.PERMISSION"
                     android:label="@string/label_permission"
                     android:description="@string/desc_permission"
                     android:protectionLevel="normal">
      </permission>

宣告具有結合之讀取和寫入 permission 的內容提供者，會讓向提供者要求讀取或寫入存取權限的實體進行存取。但是，在許多情況下，如同檔案系統中的檔案一樣，不應允許需要讀取提供者所儲存之資料的實體修改資料。設定 permission 屬性並不會允許區別資料使用者以及會影響資料完整性的互動。

範例 1：以下是宣告具有結合的讀取和寫入存取權限 permission 之內容提供者的範例。

 <provider android:name=".ContentProvider" android:permission="content.permission.READ_AND_WRITE_CONTENT"/> 

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

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

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

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

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

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

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

某些架構 (例如 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
            }
        }
    };
    

為了執行需特定權限的操作，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() 方法，而程式也將持續使用模擬的安全環境。