只要用户手动启动新事务，SAP 系统就会自动检查用户是否有权执行此事务。但是，当用户通过调用 CALL TRANSACTION 语句以编程方式启动新事务时，默认情况下不会执行这些检查。如果在此语句前未明确执行授权检查，运行 ABAP 程序的用户将能够启动原本不允许的事务。

例 1：以下代码会调用可执行任何 ABAP 程序的事务。

...
CALL TRANSACTION 'SA38'.
...

在这种情况下，运行此代码的非授权用户将能够启动任何 ABAP 程序，进而可能彻底控制系统。

如果攻击者能够提供被应用程序用于确定在打开 MQ 对象时执行哪种类型授权检查的值，他们在尝试打开原本无法访问的对象时有可能通过所有 access control 检查。

示例：下列 COBOL 代码片段从终端中读取值，并使用它们来控制 MQ 对象描述符的 MQOD-ALTERNATEUSERID 和 MQOD-ALTERNATESECURITYID 字段。

...
10 MQOD.
**    Alternate user identifier
   15 MQOD-ALTERNATEUSERID     PIC X(12).
**    Alternate security identifier
   15 MQOD-ALTERNATESECURITYID PIC X(40).
   ...
...
ACCEPT MQOD-ALTERNATEUSERID.
ACCEPT MQOD-ALTERNATESECURITYID.
CALL 'MQOPEN' USING HCONN, MQOD, OPTS, HOBJ, COMPOCODE REASON.
... 

在此示例中，攻击者可以提供使其能够在打开的 MQ 对象上通过 access control 检查的值。

总之，应禁止使用用户提供的数据或通过其他途径获取不可信任的数据，以防止攻击者控制某些敏感的数值。

正常情况下，SAP 应用程序会对执行此应用程序的用户（已登录用户）执行授权检查。但是，它可能会通过下列方式检查其他用户（非登录用户）的授权：
1. 使用 AUTHORITY-CHECK 语句，同时附加 FOR USER
2. 对指定的用户调用 AUTHORITY_CHECK 函数模块
3. 对指定的用户调用 SU_RAUTH_CHECK_FOR_USER 函数模块

尽管有时候存在执行的必要，但执行此类检查常常会导致权限扩大安全风险。如果恶意用户可以控制执行授权检查所针对的“用户 ID”输入，该用户将能够通过提供已知超级用户（如 SAP* 或 DDIC）诱使系统提供禁止该用户享有的访问权限。

即使用户无法直接控制用于授权检查的“用户 ID”，探测其他用户的授权也是一项不好的行为，需要加以避免。执行授权检查时无需明确指定登录用户 (sy-uname)。这是默认的操作方式，因为明确指定登录用户只会让攻击者有机可趁，即 sy-uname 在实际执行检查前被操控。因此，一般情况下最好跳过另外一名用户的检查授权，特别是不要明确指定登录用户。

例 1： 以下代码首先检查用户授权，然后再调用可执行任何 ABAP 程序的事务。

...
AUTHORITY-CHECK OBJECT 'S_TCODE' FOR USER v_user
ID 'TCD' FIELD 'SA38'.
IF sy-subrc = 0.
CALL TRANSACTION 'SA38'.
ELSE.
...

在此示例中，非授权用户可通过为变量 v_user 提供已知超级用户（如 SAP* 或 DDIC）启动任何 ABAP 程序。

使用通过即时调用者的类加载器检查执行任务的 Java API 时应小心谨慎。这些 API 会绕过可确保已向执行链中的所有调用者授予了必需安全权限的 SecurityManager 检查。只单独针对即时调用者的类加载器执行访问检查可能会导致权限扩大问题，执行链中的某些调用者不必具有必需的权限就能访问资源。由于这些 API 可能会削弱系统安全性，因此不应在不可信认的代码上调用它们。



来自不可信认的源或不可信认的环境的 Java Applet（具有对这些 API 的访问权限）可能会执行恶意代码并削弱系统安全性。

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

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

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

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

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

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

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

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

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

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

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