许多应用程序使用 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 允许在安全对象回调阶段临时替换 SecurityContext 中的身份验证对象。仅当 AuthenticationManager 和 AccessDecisionManager 成功处理原始身份验证对象时才会发生这种情况。RunAsManager 创建此身份验证对象。
通常，方法调用期间，开发人员使用 RunAsManager 为通过身份验证的用户配置一个或多个额外角色。此方法适用于需要访问远程应用程序的安全 Bean。由于远程应用程序可能需要不同的凭据，因而可以在调用角色与远程应用程序所需的角色之间进行转换，以便成功实施远程访问。直接接受新 Authentication 对象（称为 RunAsUserToken）作为有效 Authentication 对象，无需任何进一步的身份验证或授权检查。
为新 Authentication 对象新增角色或权限可暂时提升用户权限，允许用户采取未经授权的操作。
以下配置展示了使用 RunAsManager 针对角色为“ROLE_PEON”的用户添加角色“UBER_BOSS”，从而暂时提升此用户的权限，使其具备管理员权限，确保所有人员都能从 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：以下是一个 Android 活动示例，该示例存在 intent-filter 且未设置明确访问权限。

 <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);
...

定义针对 android.permission 命名空间的新权限可能在更新 OS 时产生意想不到的后果。如果新版 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() 方法，此时程序将继续使用模拟的安全上下文。