Salesforce 应用程序使用共享规则来控制用户权限和对数据库记录的访问权限。然而，用户共享规则并不总是在 Apex 中执行，因为 Apex 类可以使用不同的共享关键字来声明，这些共享关键字可更改规则的执行方式。类可以使用以下三个不同的共享关键字之一进行声明：

- with sharing：将强制执行用户共享规则。
- without sharing：将不会强制执行共享规则。
- inherited sharing：将强制执行调用类的共享规则。当调用类未指定共享关键字时，或者当类本身是入口点（例如 Visualforce 控制器）时，将默认强制执行用户共享规则。

当未声明任何共享关键字时，如果存在调用类，则该类将继承调用类的共享模式。否则，将不会强制执行共享规则。

示例 1：以下三个 Apex 类用于数据库查询调用的共享关键字均不安全。

    public class MyClass1 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

    public without sharing class MyClass2 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

    public inherited sharing class MyClass3 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

MyClass1 和 MyClass2 均不安全，因为它们可以在不强制执行用户共享规则的情况下检索记录。

MyClass3 更安全，因为它默认强制执行共享规则。但是，如果在显式声明使用 without sharing 的类中调用函数 getAllTheSecrets()，则仍然可以授予未经授权的访问权限。

单一 <security constraint> 元素表明程序未采用基于角色的访问控制，基于角色的访问控制是在安全 Web 应用程序中保护敏感操作的公认最佳实践。如果应用程序提供对敏感操作或数据的访问权限，则可能未部署充分的控制措施来防止未经授权的用户获取访问权限。此外，如果 <url-pattern> 中包含通配符 (*)，可能表明模式范围过大。

AccessibleObject API 允许程序员绕过由 Java 访问说明符提供的 access control 检查。特别是它让程序员能够允许反映对象绕过 Java access control，并反过来更改私有字段或调用私有方法、行为，这些通常情况下都是不允许的。

许多应用程序使用 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>

默认情况下，不能通过 GET 请求直接访问 Fusion 应用程序中的任务流：当 URL 尝试调用任务流时，会收到一个 HTTP 403 状态代码。但是，依赖隐式设置始终缺乏清晰度，且如果以下默认设置更改，可能会导致不必要的行为。

示例 1：以下代码段来自任务流定义文件，它显示了配置有隐式默认的 url-invoke-disallowed 设置的任务流示例。

...
    <task-flow-definition id="password">
        <default-activity>PasswordPrompt</default-activity>
        <view id="PasswordPrompt">
            <page>/PasswordPrompt.jsff</page>
        </view>
        <use-page-fragments/>
    </task-flow-definition>
...

在常规 JSF 应用程序中，使用 UI 组件指定的转换器和验证器来转换和验证值。提交页面时会自动进行转换和验证。Fusion 应用程序中可创建书签的视图不会执行页面提交，因此默认情况下不会执行类似的转换或验证。

示例 1：以下配置文件代码段显示了配置为不执行 paramName URL 参数的转换或验证的可创建书签的示例视图。

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

Oracle ADF Faces 组件的属性值通常只能在服务器上设置。但许多组件都允许开发人员定义可在客户端上设置的属性列表。这些组件的 unsecure 属性可以指定此列表。

目前唯一一个可在 unsecure 属性中显示的属性是 disabled，该属性允许客户端定义要启用和禁用的组件。最好不要让客户端控制只应在服务器上设置的属性值。

示例 1：以下代码显示了从用户收集密码信息并使用 unsecure 属性的 inputText 组件。

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

将加密密钥存储在静态类字段中时，可访问进程内存（如经过 root 的设备）或进程内存转储（如故障转储）的实体可轻松恢复该密钥。

虽然为内容提供者定义单独的读取和写入权限是个不错的主意，但只定义 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"/>