內容安全性原則 (CSP) 是一種宣告式安全性標頭，可讓開發人員指定瀏覽器中允許的安全性相關行為，包括可從中擷取內容的位置允許清單。除了程式碼中的輸入驗證和檢查允許清單外，它還提供額外一層的安全性，以防禦重要弱點，例如，Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。但設定不當的標頭無法提供這種額外一層的安全性。該原則藉助於 15 個指令進行定義，其中包括 8 個用於控制資源存取的指令，即：script-src、img-src、object-src、style_src、font-src、media-src、frame-src、connect-src。這 8 個指令都將一個來源清單做為值，指定網站可存取的網域，以使用該指令所涵蓋的功能。開發人員可使用萬用字元 * 來指示所有或部分來源。其他來源清單關鍵字 (例如 'unsafe-inline' 和 'unsafe-eval') 提供更精細的方式來控制 script 執行，但這些是潛在有害的關鍵字。所有指令都不是強制性的。瀏覽器允許未列示指令的所有來源，或從選用的 default-src 指令衍生值。此外，此標頭的規格隨著時間的推移而不斷演變。在第 23 版之前的 Firefox 和第 10 版之前的 IE 中，其實作為 X-Content-Security-Policy，而在第 25 版之前的 Chrome 中，則實作為 X-Webkit-CSP。兩個名稱都已棄用，取代為現在的標準名稱 Content Security Policy。鑒於指令的數目、兩個棄用的替代名稱，以及對待多次出現之同一標頭和單一標頭中重複指令的方式，開發人員很可能會錯誤地設定此標頭。

範例 1：以下程式碼會設定過度寬鬆且不安全的 default-src 指令：

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy policy-directives="default-src '*'" />
        </headers>
    </http>

在 HTML5 之前，網頁瀏覽器會強制執行相同來源原則，確保在使用 JavaScript 存取網頁內容時，JavaScript 和網頁來自相同的網域。若不使用相同來源策略 (Same Origin Policy)，惡意的網站可使用用戶端的憑證來執行 JavaScript，從其他網站載入敏感的資訊，從中挑選出資訊並將資訊回傳給攻擊者。HTML5 使 JavaScript 可以在定義稱為 Access-Control-Allow-Origin 的新 HTTP 標頭時，存取不同網域間的資料。Web 伺服器可使用此標頭，定義允許使用跨來源要求存取其網域的其他網域。但是，定義標頭時請謹慎小心，因為過度許可的 CORS 原則會允許惡意應用程式以不當方式與受害應用程式通訊，進行導致詐騙、資料竊取、轉送和其他攻擊。

範例 1：以下是使用萬用字元在程式上指定允許應用程式與哪些網域通訊的範例。

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

使用 * 做為 Access-Control-Allow-Origin 表頭的值，表示應用程式的資料可以讓在任何網域上執行的 JavaScript 存取。

HTML5 的新功能之一便是跨文件訊息。此功能可允許 Script 將訊息發佈至其他視窗。相應的 API 允許使用者指定目標視窗的來源。但是，指定目標來源時應特別小心，因為過度允許的目標來源會允許惡意指令碼以不適當的方式與受害者視窗通訊，導致欺騙、資料遭竊取、傳遞和其他攻擊。

範例 1：以下範例使用萬用字元來以程式化方式指定要傳送之訊息的目標來源。

    WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
    webview.postWebMessage(message, Uri.parse("*"));

使用 * 作為目標來源值，代表指令碼會傳送訊息至視窗而不論其來源。

依預設，瀏覽器不會將包含來自 HTTPS 之要求的參照標頭傳送給未加密的 HTTP 連結。不過，如果要求目的地也是 HTTPS，則不論來源為何，都會傳送標頭。開發人員可能將敏感資訊留在 URL 中，這些 URL 會透過參照標頭而洩漏給第三方網站。引入 Referrer-Policy 標頭可控制與參照標頭相關的瀏覽器行為。Unsafe-URL 選項會移除所有限制，並傳送包含每個要求的參照標頭。

範例 1：以下程式碼會將受 Spring Security 保護的應用程式設定為停用預設的保護參照原則：

	<http auto-config="true">
        ...
        <headers>
            ...
            <referrer-policy policy="unsafe-url"/>
        </headers>
	</http>

內容安全性原則 (CSP) 是一種宣告式安全性標頭，可讓開發人員指示在網頁瀏覽器中轉譯時，允許網站從哪些網域載入內容或起始到哪些網域的連線。除了程式碼中的輸入驗證和檢查允許清單外，它還提供額外一層的安全性，以防禦重要弱點，例如，Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。

Content-Security-Policy-Report-Only 標頭為 Web 應用程式作者和管理員提供了監視安全性原則的功能，而不是強制執行原則。此標頭通常在實驗和/或開發網站的安全性原則時使用。當某原則被視為有效時，您可透過改用 Content-Security-Policy 標頭欄位來強制執行此原則。

範例 1：下列程式碼會在 Report-Only 模式中設定內容安全性原則：

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
        </headers>
    </http>

允許鍵盤延伸讀取使用者輸入的每個單一按鍵輸入。通常使用第三方鍵盤來簡化文字輸入或新增其他 Emoji，它們可能會記錄使用者輸入的內容，甚至將其傳送至遠端伺服器進行處理。還可能會散佈惡意鍵盤作為鍵盤記錄木馬程式，讀取使用者輸入的每個金鑰值，以竊取諸如憑證或信用卡號等敏感資料。

延伸會在其檢視控制器中接收來自主機應用程式的資料，並且無法實作 SLComposeServiceViewController isContentValid 以在使用收到的不可信賴的資料前對其進行驗證。

範例 1：以下延伸檢視控制器會接收來自主機應用程式的資料，但無法實作回呼方法來進行驗證：

    #import <MobileCoreServices/MobileCoreServices.h>

    @interface ShareViewController : SLComposeServiceViewController
        ...
    @end

    @interface ShareViewController ()
        ...
    @end

    @implementation ShareViewController

    - (void)didSelectPost {
        NSExtensionItem *item = self.extensionContext.inputItems.firstObject;
        NSItemProvider *itemProvider = item.attachments.firstObject;
        ...
        // Use the received items
        ...
        [self.extensionContext completeRequestReturningItems:@[] completionHandler:nil];
    }

    ...

    @end

第三方應用程式或 webview 使用 URL 與您的應用程式通訊時，接收應用程式應確認傳送者為期望通訊之應用程式允許清單的成員。接收應用程式可以選擇在驗證呼叫 URL 來源時是使用 UIApplicationDelegate application:openURL:options: 還是 UIApplicationDelegate application:openURL:sourceApplication:annotation: 委派方法。

範例 1：UIApplicationDelegate application:openURL:options: 委派方法的以下實作無法確認 IPC 呼叫的傳送者，而是僅處理呼叫 URL：

    - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<NSString *,id> *)options {
        NSString *theQuery = [[url query] stringByRemovingPercentEncoding:NSUTF8StringEncoding];
        NSArray *chunks = [theQuery componentsSeparatedByString:@"&"];
        for (NSString* chunk in chunks) {
            NSArray *keyval = [chunk componentsSeparatedByString:@"="]; NSString *key = [keyval objectAtIndex:0];
            NSString *value = [keyval objectAtIndex:1];
            // Do something with your key and value
        }
        return YES;
    }

第三方應用程式或 webview 使用某個 URL 與您的應用程式通訊時，接收應用程式應先驗證呼叫 URL，然後再執行進一步的動作。接收應用程式可以選擇是使用 UIApplicationDelegate application:didFinishLaunchingWithOptions: 還是 UIApplicationDelegate application:willFinishLaunchingWithOptions: 委派方法來開啟呼叫 URL。

範例 1：UIApplicationDelegate application:didFinishLaunchingWithOptions: 委派方法的以下實作無法驗證呼叫 URL 並且總是處理不可信賴的 URL：

    - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NS Dictionary *)launchOptions {
        return YES;
    }

應用程式可能會為第三方應用程式註冊自訂 URL 架構，以與其進行通訊。雖然這是一個簡單的 IPC 通道，但可能會使您的應用程式暴露於「URL 架構劫持」。由於任何應用程式皆可註冊 URL 架構 (只要不是 Apple 所保留的)，因此惡意應用程式可能會註冊您的應用程式所使用的相同架構，從而導致未定義的行為。根據 Apple 說明文件：「如果多個第三方應用程式同時註冊以處理同一 URL 架構，目前沒有程序可以判定將為哪個應用程式提供該架構」。如果惡意應用程式安裝於您的應用程式之前，它可能會註冊該架構並阻止您的應用程式成功安裝。或者，如果惡意應用程式安裝於您的應用程式之後並成功完成架構註冊，則可能會從您的應用程式劫持該架構。

Android 備份服務允許應用將持續性資料儲存到遠端雲端儲存空間，以便未來為應用資料提供復原點。

Android 應用程式可設定此備份服務，方法是透過將 allowBackup 屬性設定為 true (預設值) 並定義 <application> 標籤上的 backupAgent 屬性。

但是 Android 不保證使用備份功能時資料的安全性，這是因為每一種裝置的雲端儲存和傳輸都有所不同的緣故。

使用者在電腦上啟用 USB 高容量儲存裝置來傳輸檔案時，使用者可任意讀取或修改儲存在外部儲存裝置的檔案。另外，即使解除安裝寫入檔案的的應用程式，外部儲存裝置上仍會保留這些檔案。這些限制會危及寫入儲存裝置的敏感資訊，或是讓攻擊者修改程式依賴的外部檔案，將惡意資料插入程式中。

範例 1：在以下程式碼中，Environment.getExternalStorageDirectory() 會將參照傳回 Android 裝置的外部儲存裝置。

 private void WriteToFile(String what_to_write) {
        try{
            File root = Environment.getExternalStorageDirectory();
            if(root.canWrite()) {
                File dir = new File(root + "write_to_the_SDcard");
                File datafile = new File(dir, number + ".extension");
                FileWriter datawriter = new FileWriter(datafile);
                BufferedWriter out = new BufferedWriter(datawriter);
                out.write(what_to_write);
                out.close();
             }
        }
   }

使用 MODE_WORLD_READBLE 或 MODE_WORLD_WRITEABLE 儲存於 Android 內部儲存空間的資料可由裝置上的所有應用程式存取。這不僅是拒絕防止資料損毀，且在敏感資訊的情況下違反使用者隱私權和安全性顧慮。

將資料儲存至金鑰鏈時，需要設定定義何時可以存取項目的可存取性層級。可能的可存取性層級包括：

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
重新啟動後，無法存取金鑰鏈項目中的資料，直到使用者進行一次裝置解除鎖定。
首次解除鎖定後，資料會保持可存取狀態，直到下次重新啟動。對於背景應用程式需要存取的項目，建議這樣做。具有此屬性的項目不會移轉至新裝置。因此，從不同裝置的備份還原後，不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleAlways:
不論裝置是否已鎖定，始終可以存取金鑰鏈項目中的資料。
如果使用應用程式，則不建議這樣做。使用加密的備份時，具有此屬性的項目會移轉至新裝置。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
金鑰鏈中的資料僅在裝置解除鎖定時才可存取。僅當裝置設定有密碼時才可使用。
對於只需在應用程式於前景執行時可供存取的項目，建議這樣做。具有此屬性的項目絕不會移轉至新裝置。備份還原至新裝置後，這些項目會遺失。對於未設定密碼的裝置，沒有任何項目可儲存在此類別中。停用裝置密碼會導致此類別中的所有項目遭到刪除。
可用於 iOS 8.0 及更新版本。

-kSecAttrAccessibleAlwaysThisDeviceOnly:
不論裝置是否已鎖定，始終可以存取金鑰鏈項目中的資料。
如果使用應用程式，則不建議這樣做。具有此屬性的項目不會移轉至新裝置。因此，從不同裝置的備份還原後，不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenUnlocked:
金鑰鏈中的資料僅當使用者解除鎖定裝置時才可存取。
對於只需在應用程式於前景執行時可供存取的項目，建議這樣做。使用加密的備份時，具有此屬性的項目會移轉至新裝置。
這是在未明確設定可存取性常數時新增的金鑰鏈項目的預設值。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
金鑰鏈中的資料僅當使用者解除鎖定裝置時才可存取。
對於只需在應用程式於前景執行時可供存取的項目，建議這樣做。具有此屬性的項目不會移轉至新裝置。因此，從不同裝置的備份還原後，不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

即使是使用可還原至任何裝置的未加密備份，不包含 ThisDeviceOnly 的可存取性層級仍會備份至 iCloud 和 iTunes。這可能會導致隱私問題，具體視所儲存資料的敏感和隱私程度而定。

範例 1：在以下範例中，金鑰鏈項目始終受到保護，開啟裝置電源和解除鎖定時除外，但金鑰鏈項目會備份至 iCloud 以及未加密的 iTunes 備份：

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure KeyChain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:(__bridge id)kSecAttrAccessibleWhenUnlocked forKey:(__bridge id) kSecAttrAccessible];

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...

HTTP(S) 回應可能包含敏感資料，如階段作業 Cookie 和 API 權杖。 基於效能原因，URL 載入系統將快取所有 HTTP(S) 回應，在不加密的情況下將其儲存在不安全的共用儲存區中。

範例 1： 下列程式碼在共用儲存空間中安裝 HTTP(S) 回應快取：

    protected void onCreate(Bundle savedInstanceState) {
       ...

       try {
           File httpCacheDir = new File(context.getExternalCacheDir(), "http");
           long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
           HttpResponseCache.install(httpCacheDir, httpCacheSize);
       } catch (IOException e) {
           Log.i(TAG, "HTTP response cache installation failed:" + e);
       }
    }

    protected void onStop() {
       ...

       HttpResponseCache cache = HttpResponseCache.getInstalled();
       if (cache != null) {
           cache.flush();
       }
   }

HTTP(S) 回應可能包含敏感資料，如階段作業 Cookie 和 API 權杖。基於效能原因，URL 載入系統將快取所有 HTTP(S) 回應，在不加密的情況下將其儲存在 {app ID}/Library/Caches/com.mycompany.myapp/Cache.db* 檔案中。
開發人員可能認為透過將 URLCache 類別的 diskCapacity 或 memoryCapacity 屬性設定為 0，可有效地停用 HTTP(S) 回應快取系統。但 NSURLCache 說明文件指出，僅當裝置的記憶體或裝置空間均不足時，磁碟上和記憶體內的快取才會被截斷成配置的大小。系統應該使用這兩項設定來釋放系統資源並提高效能，而非將其作為安全性控制。

資料保護 API 設計為允許應用程式宣告何時可以存取金鑰鏈中的項目以及檔案系統上儲存的檔案。這適用於大多數的檔案和資料庫 API，包括 NSFileManager、CoreData、NSData 和 SQLite。開發人員可以藉由將四種保護類別之一指定給某個指定資源，指示基礎檔案系統使用衍生自裝置 UID 和使用者密碼兩者的金鑰，或是使用完全以裝置 UID 為基礎的金鑰，對該資源進行加密 (以及何時自動對其進行解密)。

資料保護類別針對 NSFileManager 定義，而常數則應該被指派為與 NSFileManager 執行個體相關聯之 NSDictionary 中的 NSFileProtectionKey 金鑰值，以及可以透過使用 NSFileManager 函數 (包括 setAttributes:ofItemAtPath:error:、attributesOfItemAtPath:error: 和 createFileAtPath:contents:attributes:) 建立檔案或修改其資料保護類別。此外，相對應的資料保護常數會針對 NSData 物件定義為 NSDataWritingOptions，以便可以做為 options 引數傳遞到 NSData 函數 writeToURL:options:error: 和 writeToFile:options:error:。NSFileManager 和 NSData 的各種資料保護類別常數定義如下所示：

-NSFileProtectionComplete, NSDataWritingFileProtectionComplete:
資源會以加密格式儲存在磁碟，當裝置處於鎖定狀態或者正在開機時，將無法進行讀取或寫入。
可用於 iOS 4.0 及更新版本。
-NSFileProtectionCompleteUnlessOpen, NSDataWritingFileProtectionCompleteUnlessOpen:
資源會以加密格式儲存在磁碟。當裝置處於鎖定狀態時，可以建立資源，但是一旦關閉資源，就無法再次開啟，直到裝置解除鎖定。如果在解除鎖定時開啟了資源，則可以如常繼續存取資源，即使使用者鎖定了裝置也無妨。
可用於 iOS 5.0 及更新版本。
-NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication:
資源會以加密格式儲存在磁碟，只有在裝置開機之後，才能存取資源。在使用者首次解除鎖定裝置之後，您的應用程式可以存取資源，即使使用者之後鎖定了裝置，還是可以繼續存取。
可用於 iOS 5.0 及更新版本。
-NSFileProtectionNone, NSDataWritingFileProtectionNone:
資源沒有與其相關聯的特殊保護。任何時候都可以讀取或寫入資源。
可用於 iOS 4.0 及更新版本。

所以，雖然以 NSFileProtectionCompleteUnlessOpen 或 NSFileProtectionCompleteUntilFirstUserAuthentication 標記檔案將會使用衍生自使用者密碼和裝置 UID 的金鑰為其加密，但是在某些情況下資料還是保持可存取的狀態。因此，使用 NSFileProtectionCompleteUnlessOpen 或 NSFileProtectionCompleteUntilFirstUserAuthentication 時應該仔細進行檢閱，以確定是否保證提供進一步的 NSFileProtectionComplete 保護。

範例 1：在以下範例中，只有在使用者開啟裝置並首次提供密碼後 (直到下次重新開機)，所指定的檔案才受到保護：

...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSDictionary *protection = [NSDictionary dictionaryWithObject:NSFileProtectionCompleteUntilFirstUserAuthentication forKey:NSFileProtectionKey];
...
[[NSFileManager defaultManager] setAttributes:protection ofItemAtPath:filepath error:nil];
...
BOOL ok = [testToWrite writeToFile:filepath atomically:YES encoding:NSUnicodeStringEncoding error:&err];
...

範例 2：在以下範例中，只有在使用者開啟裝置並首次提供密碼後 (直到下次重新開機)，所指定的資料才受到保護：

...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSData *textData = [textToWrite dataUsingEncoding:NSUnicodeStingEncoding];
...
BOOL ok = [textData writeToFile:filepath options:NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication error:&err];
...

金鑰鏈可存取性常數設計為允許應用程式藉此宣告何時可以存取金鑰鏈中的項目。藉由將其中一種可存取性常數指定給指定金鑰鏈項目，開發人員可以指示基礎檔案系統使用衍生自裝置 UID 和使用者密碼的金鑰，或是使用完全以裝置 UID 為基礎的金鑰，對該項目進行加密 (以及何時自動對其進行解密)。

這意味著金鑰鏈可存取性常數應指定為金鑰鏈屬性字典中 kSecAttrAccessible 金鑰的值。各個金鑰鏈可存取性常數的定義如下所示：

-kSecAttrAccessibleAfterFirstUnlock:
重新啟動後，無法存取金鑰鏈項目中的資料，直到使用者進行一次裝置解除鎖定。
首次解除鎖定後，資料會保持可存取狀態，直到下次重新啟動。對於背景應用程式需要存取的項目，建議這樣做。使用加密的備份時，具有此屬性的項目會移轉至新裝置。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
重新啟動後，無法存取金鑰鏈項目中的資料，直到使用者進行一次裝置解除鎖定。
首次解除鎖定後，資料會保持可存取狀態，直到下次重新啟動。對於背景應用程式需要存取的項目，建議這樣做。具有此屬性的項目不會移轉至新裝置。因此，從不同裝置的備份還原後，不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleAlways:
不論裝置是否已鎖定，始終可以存取金鑰鏈項目中的資料。
如果使用應用程式，則不建議這樣做。使用加密的備份時，具有此屬性的項目會移轉至新裝置。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
金鑰鏈中的資料僅在裝置解除鎖定時才可存取。僅當裝置設定有密碼時才可使用。
對於只需在應用程式於前景執行時可供存取的項目，建議這樣做。具有此屬性的項目絕不會移轉至新裝置。備份還原至新裝置後，這些項目會遺失。對於未設定密碼的裝置，沒有任何項目可儲存在此類別中。停用裝置密碼會導致此類別中的所有項目遭到刪除。
可用於 iOS 8.0 及更新版本。

-kSecAttrAccessibleAlwaysThisDeviceOnly:
不論裝置是否已鎖定，始終可以存取金鑰鏈項目中的資料。
如果使用應用程式，則不建議這樣做。具有此屬性的項目不會移轉至新裝置。因此，從不同裝置的備份還原後，不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenUnlocked:
金鑰鏈中的資料僅當使用者解除鎖定裝置時才可存取。
對於只需在應用程式於前景執行時可供存取的項目，建議這樣做。使用加密的備份時，具有此屬性的項目會移轉至新裝置。
這是在未明確設定可存取性常數時新增的金鑰鏈項目的預設值。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
金鑰鏈中的資料僅當使用者解除鎖定裝置時才可存取。
對於只需在應用程式於前景執行時可供存取的項目，建議這樣做。具有此屬性的項目不會移轉至新裝置。因此，從不同裝置的備份還原後，不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

所以，雖然以 kSecAttrAccessibleAfterFirstUnlock 標記金鑰鏈項目將會使用衍生自使用者密碼和裝置 UID 的金鑰進行加密，但是在某些情況下資料仍然保持可存取狀態。因此，使用 kSecAttrAccessibleAfterFirstUnlock 時應該仔細進行檢閱，確定是否保證提供進一步的保護。

範例 1：在以下範例中，只有在使用者開啟裝置電源並首次提供密碼後 (直到下次重新開機)，所指定的金鑰鏈項目才受到保護：

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure KeyChain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:(__bridge id)kSecAttrAccessibleAfterFirstUnlock forKey:(__bridge id) kSecAttrAccessible];

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...

資料保護 API 設計為允許應用程式宣告何時可以存取金鑰鏈中的項目以及檔案系統上儲存的檔案。這適用於大多數的檔案和資料庫 API，包括 NSFileManager、CoreData、NSData 和 SQLite。開發人員可以藉由將四種保護類別之一指定給某個指定資源，指示基礎檔案系統使用衍生自裝置 UID 和使用者密碼兩者的金鑰，或是使用完全以裝置 UID 為基礎的金鑰，對該資源進行加密 (以及何時自動對其進行解密)。

資料保護類別針對 NSFileManager 定義，而常數則應該被指派為與 NSFileManager 執行個體相關聯之 NSDictionary 中的 NSFileProtectionKey 金鑰值，以及可以透過使用 NSFileManager 函數 (包括 setAttributes:ofItemAtPath:error:、attributesOfItemAtPath:error: 和 createFileAtPath:contents:attributes:) 建立檔案或修改其資料保護類別。此外，相對應的資料保護常數會針對 NSData 物件定義為 NSDataWritingOptions，以便可以做為 options 引數傳遞到 NSData 函數 writeToURL:options:error: 和 writeToFile:options:error:。NSFileManager 和 NSData 的各種資料保護類別常數定義如下所示：

-NSFileProtectionComplete, NSDataWritingFileProtectionComplete:
資源會以加密格式儲存在磁碟，當裝置處於鎖定狀態或者正在開機時，將無法進行讀取或寫入。
可用於 iOS 4.0 及更新版本。
-NSFileProtectionCompleteUnlessOpen, NSDataWritingFileProtectionCompleteUnlessOpen:
資源會以加密格式儲存在磁碟。當裝置處於鎖定狀態時，可以建立資源，但是一旦關閉資源，就無法再次開啟，直到裝置解除鎖定。如果在解除鎖定時開啟了資源，則可以如常繼續存取資源，即使使用者鎖定了裝置也無妨。
可用於 iOS 5.0 及更新版本。
-NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication:
資源會以加密格式儲存在磁碟，只有在裝置開機之後，才能存取資源。在使用者首次解除鎖定裝置之後，您的應用程式可以存取資源，即使使用者之後鎖定了裝置，還是可以繼續存取。
可用於 iOS 5.0 及更新版本。
-NSFileProtectionNone, NSDataWritingFileProtectionNone:
資源沒有與其相關聯的特殊保護。任何時候都可以讀取或寫入資源。
可用於 iOS 4.0 及更新版本。

即使 iOS 裝置上的所有檔案 (包括未明確指派有資料保護類別的檔案) 都以加密格式儲存，指定 NSFileProtectionNone 也會導致使用完全以裝置 UID 為基礎的衍生金鑰進行加密。如此一來，在裝置開機的任何時候 (包括以密碼鎖定時或正在開機時)，此類檔案都會處於可存取的狀態。因此，使用 NSFileProtectionNone 時應該仔細進行檢閱，以確定是否保證使用較嚴格的資料保護類別提供進一步的保護。

範例 1：在以下範例中，指定的檔案未受保護 (在裝置開機的任何時候均可存取)：

...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSDictionary *protection = [NSDictionary dictionaryWithObject:NSFileProtectionNone forKey:NSFileProtectionKey];
...
[[NSFileManager defaultManager] setAttributes:protection ofItemAtPath:filepath error:nil];
...
BOOL ok = [testToWrite writeToFile:filepath atomically:YES encoding:NSUnicodeStringEncoding error:&err];
...

範例 2：在以下範例中，指定的資料未受保護 (在裝置開機的任何時候均可存取)：

...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSData *textData = [textToWrite dataUsingEncoding:NSUnicodeStingEncoding];
...
BOOL ok = [textData writeToFile:filepath options:NSDataWritingFileProtectionNone error:&err];
...

金鑰鏈可存取性常數設計為允許應用程式藉此宣告何時可以存取金鑰鏈中的項目。藉由將其中一種可存取性常數指定給某個指定金鑰鏈項目，開發人員可以指示基礎檔案系統使用衍生自裝置 UID 和使用者密碼的金鑰，或是使用完全以裝置 UID 為基礎的金鑰，對該項目進行加密 (以及何時自動對其進行解密)。

這意味著金鑰鏈可存取性常數應指定為金鑰鏈屬性字典中 kSecAttrAccessible 金鑰的值。各個金鑰鏈可存取性常數的定義如下所示：

-kSecAttrAccessibleAfterFirstUnlock:
重新啟動後，無法存取金鑰鏈項目中的資料，直到使用者進行一次裝置解除鎖定。
首次解除鎖定後，資料會保持可存取狀態，直到下次重新啟動。對於背景應用程式需要存取的項目，建議這樣做。使用加密的備份時，具有此屬性的項目會移轉至新裝置。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
重新啟動後，無法存取金鑰鏈項目中的資料，直到使用者進行一次裝置解除鎖定。
首次解除鎖定後，資料會保持可存取狀態，直到下次重新啟動。對於背景應用程式需要存取的項目，建議這樣做。具有此屬性的項目不會移轉至新裝置。因此，從不同裝置的備份還原後，不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleAlways:
不論裝置是否已鎖定，始終可以存取金鑰鏈項目中的資料。
如果使用應用程式，則不建議這樣做。使用加密的備份時，具有此屬性的項目會移轉至新裝置。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
金鑰鏈中的資料僅在裝置解除鎖定時才可存取。僅當裝置設定有密碼時才可使用。
對於只需在應用程式於前景執行時可供存取的項目，建議這樣做。具有此屬性的項目絕不會移轉至新裝置。備份還原至新裝置後，這些項目會遺失。對於未設定密碼的裝置，沒有任何項目可儲存在此類別中。停用裝置密碼會導致此類別中的所有項目遭到刪除。
可用於 iOS 8.0 及更新版本。

-kSecAttrAccessibleAlwaysThisDeviceOnly:
不論裝置是否已鎖定，始終可以存取金鑰鏈項目中的資料。
如果使用應用程式，則不建議這樣做。具有此屬性的項目不會移轉至新裝置。因此，從不同裝置的備份還原後，不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenUnlocked:
金鑰鏈中的資料僅當使用者解除鎖定裝置時才可存取。
對於只需在應用程式於前景執行時可供存取的項目，建議這樣做。使用加密的備份時，具有此屬性的項目會移轉至新裝置。
這是在未明確設定可存取性常數時新增的金鑰鏈項目的預設值。
可用於 iOS 4.0 及更新版本。

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
金鑰鏈中的資料僅當使用者解除鎖定裝置時才可存取。
對於只需在應用程式於前景執行時可供存取的項目，建議這樣做。具有此屬性的項目不會移轉至新裝置。因此，從不同裝置的備份還原後，不會顯示這些項目。
可用於 iOS 4.0 及更新版本。

即使 iOS 裝置上的所有檔案 (包括未明確指派有金鑰鏈可存取性常數的檔案) 都以加密格式儲存，指定 kSecAttrAccessibleAlways 也會導致使用完全以裝置 UID 為基礎的衍生金鑰進行加密。如此一來，在裝置開機的任何時候 (包括以密碼鎖定時或正在開機時)，此類檔案都會處於可存取的狀態。因此，使用 kSecAttrAccessibleAlways 時應該仔細進行檢閱，確定是否能保證具有較嚴格金鑰鏈可存取性層級的進一步保護。

範例 1：在以下範例中，指定的檔案未受保護 (只要裝置開機便可存取)：

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure KeyChain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:(__bridge id)kSecAttrAccessibleAlways forKey:(__bridge id) kSecAttrAccessible];

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...