只要使用者手動啟動新交易，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. 在新增 FOR USER 的同時使用陳述式 AUTHORITY-CHECK
2. 透過指定的使用者呼叫函數模組 AUTHORITY_CHECK
3. 透過指定的使用者呼叫函數模組 SU_RAUTH_CHECK_FOR_USER

雖然這些檢查有時是必要的，但通常會造成權限提升的安全性風險。控制據以執行授權檢查之「使用者 id」輸入的惡意使用者，能夠欺騙系統提供已知的超級使用者 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> 元素表示程式並未使用以角色為基礎的存取控制，這對保護網路應用程式的敏感作業而言，是一般公認的最佳作法。若應用程式提供敏感作業或資料的存取權限，可能沒有足夠的控制機制來防止未授權的使用者取得存取權限。此外，若 <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>