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> 元素表示程式並未使用以角色為基礎的存取控制，這對保護網路應用程式的敏感作業而言，是一般公認的最佳作法。若應用程式提供敏感作業或資料的存取權限，可能沒有足夠的控制機制來防止未授權的使用者取得存取權限。此外，若 <url-pattern> 中有萬用字元 (*)，這可能表示模式範圍過大。

透過 AccessibleObject API，程式設計人員可以避開 Java 存取規範提供的存取控制檢查。特別是，程式設計人員可藉此允許回傳的物件避開 Java 存取控制，轉而變更私有欄位的值或呼叫私有方法、行為 (通常這是不允許的)。

多數應用程式使用 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>

依照預設，Fusion 應用程式中的工作流程無法直接從 GET 要求中存取：每次 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：以下程式碼示範了 inputText 元件，該元件會從使用者收集密碼資訊，並使用 unsecure 屬性。

...
    <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：以下是一個範例，說明有 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"/>