Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) 攻擊是一種側通道攻擊，可讓攻擊者竊取 HTTP 回應中所包含之經由已啟用 SSL/TLS 的通道進行傳輸的敏感資訊。所有現有的 SSL/TLS 版本和密碼都容易受到此攻擊。如果滿足以下三個條件，則攻擊者可能成功對應用程式發起 BREACH 攻擊：

1. 應用程式在回應中傳輸機密資訊 (例如，防 CSRF 權杖)。
2. 應用程式在包含機密資訊的同一回應中反映使用者輸入。
3. Web 伺服器配置為使用 HTTP 壓縮。

使用 gzip 壓縮之回應的大小取決於在其內容中發現的重複資料數量。因此，字元重複出現的次數越多，回應大小越小。這樣，攻擊者便可使用 HTTP 壓縮做為預測，用於指示攻擊者透過反映的參數值提供給應用程式的猜測是否正確。如果猜測的字元符合機密資訊中對應的字元，則壓縮的回應大小較小。攻擊者可能使用此程序，透過分析每個要求的壓縮比率，逐字元地取得完整機密資訊。

即使應用程式已設定為經由安全通道提供內容，攻擊者也可能使用此技術，從 HTTP 回應中擷取機密資訊。

若要評估應用程式是否容易受到 BREACH 攻擊，請先檢閱應用程式是否已配置為啟用 HTTP 壓縮。如果是，則針對包含要保護之機密資訊的每個回應，評估其中是否包含使用者輸入。

報告此問題是因為 Django 應用程式已配置為使用 CSRF 權杖和 GZip 壓縮：

MIDDLEWARE = (
  ...
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.middleware.gzip.GZipMiddleware',
  ...
)

在以下情況中會出現私人健康狀況資訊洩漏：

1. 使用者的健康狀況資訊進入程式。

2. 資料寫入到外部位置，例如主控台、檔案系統或網路。
範例 1：以下程式碼會在登入裝置時從 HealthKit 存放區擷取使用者血型並將其傳送至伺服器。雖然許多開發人員認定記錄檔是儲存所有資料的安全位置，但不應對其絕對信賴，特別是關係到隱私問題時。

    ...
    HKHealthStore healthStore = new HKHealthStore();
    HKBloodTypeObject blood = healthStore.GetBloodType(null);

    NSLog("%@", blood.BloodType);

	var urlWithParams = String.format(TOKEN_URL, block.BloodType);
	var responseString = await client.GetStringAsync(urlWithParams);
    ...

注意： Apple 登入 API (位於比 NSLog 函數低的層級) 允許開發人員建立一個可讀取裝置上所有記錄檔的應用程式 (即使未擁有其他應用程式)。

若裝置遺失或被盜，就會產生關於維護使用者資料隱私的其他擔憂。 攻擊者一旦擁有 iOS 裝置，便可能透過 USB 連接裝置而存取大量資料。 可以輕鬆存取 iOS Property Lists (plists) 等檔案及 SQLite 資料庫，並且可以洩露個人資訊。 一般的原則是，不應將私人健康狀況詳細資料在未加保護的情況下儲存在檔案系統中。

範例 2： 下列程式碼會新增使用者血型到使用者預設值清單，並立即將其儲存至 plist 檔案。

    ...
    HKHealthStore healthStore = new HKHealthStore();
    HKBloodTypeObject blood = healthStore.GetBloodType(null);

    // Add blood type to user defaults
	NSUserDefaults.StandardUserDefaults.SetString(blood.BloodType, "bloodType");
    ...

有鑑於私人資料經常遭到錯誤處理，收集和管理私人資料方面的規範在日益增加。 針對健康狀況資訊，各組織應遵守以下一或多項聯邦和州的規定：

- Safe Harbor Privacy Framework [2]

- Gramm-Leach Bliley Act (GLBA) [3]

- Health Insurance Portability and Accountability Act (HIPAA) [4]

- California SB-1386 [5]

雖已制定規範，但隱私違反的情況仍持續發生。

如果使用記憶體後不進行清除，就可能會洩露儲存在記憶體上的敏感資料 (例如密碼、社會安全號碼、信用卡號碼等)。通常，會使用 String 來儲存敏感資料，然而，因為 String 物件為不可變，因此只能使用 JVM 記憶體回收器從記憶體移除 String 值。除非 JVM 的記憶體很少，否則不需要執行記憶體回收器，所以無法保證記憶體回收器會在何時執行。在應用程式意外結束時，應用程式的記憶體傾印可能會洩露敏感資料。

範例 1：下列程式碼會將來自字元陣列的密碼轉換成 String。

private JPasswordField pf;
...
final char[] password = pf.getPassword();
...
String passwordAsString = new String(password);

HTTP 要求利用 GET 方法來允許 URL 和要求參數在瀏覽器的 URL 快取、中繼伺服器和伺服器記錄檔中進行快取。如此可能會向未擁有該筆資料適當權限的個人暴露敏感資訊。
範例 1：下列程式碼會使用 GET HTTP 方法而非 POST 方法來進行 HTTP 要求。

...
	NSString * const USER_URL = @"https://www.somesvr.com/someapp/user";
...
	NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
	[request setHTTPMethod:@"GET"];
...

範例 2：如果應用程式使用 NSURLRequest，則預設 HTTP 方法為 GET。

...
	NSURLRequest *theRequest=[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://www.apple.com/"]
                        cachePolicy:NSURLRequestUseProtocolCachePolicy
                    timeoutInterval:60.0];
	NSURLConnection *theConnection=[[NSURLConnection alloc] initWithRequest:theRequest delegate:self];
	if (theConnection) {
    	// Create the NSMutableData to hold the received data.
    	// receivedData is an instance variable declared elsewhere.
    		receivedData = [[NSMutableData data] retain];
	} else {
...

在建立包含表單形式的使用者憑證、使用者名稱/密碼組或用戶端憑證的 NSURLCredential 實例時，需要定義持續性屬性。可能的值如下：

-NSURLCredentialPersistenceNone：不應儲存憑證。
-NSURLCredentialPersistenceForSession：只能儲存憑證用於此階段作業。
-NSURLCredentialPersistencePermanent：憑證應儲存在金鑰鏈中。
-NSURLCredentialPersistenceSynchronizable：憑證應永久儲存在金鑰鏈中，並且應分發至以擁有 Apple ID 為基礎的其他裝置上。

NSURLCredentialPersistenceSynchronizable 屬性表示憑證分發以及在 Apple 雲端環境中儲存。視應用程式的隱私要求而定，在 Apple 雲端環境中儲存憑證可能不被接受。

範例 1：以下程式碼片段將建立一個可同步處理的憑證，此憑證將分發至其他裝置和 iCloud：

    ...
    NSURLCredential *credential = [NSURLCredential credentialWithUser:user password:password persistence:NSURLCredentialPersistenceSynchronizable]; 
    NSURLCredentialStorage *shared = [NSURLCredentialStorage sharedCredentialStorage];
    [shared setDefaultCredential:credential forProtectionSpace:protectionSpace]; 
    ...

如果敏感資料以未加密格式保存在磁碟中，可能會發生 Privacy Volation。


範例 1： DataVisualization 控制會從 XML 資料來源 SensitiveXMLData 產生敏感財務資訊的圖形，下列 ASPX 程式碼可將其個體化：

        <asp:Chart ID="Chart1" runat="server" ImageLocation="~/Temporary/Graph"
            ImageType="Jpeg" DataSourceID="SensitiveXMLData" ImageStorageMode="UseImageLocation">
            <series>
                .
                .
                .
            </series>
            <chartareas>
                <asp:ChartArea Name="ChartArea1">
                </asp:ChartArea>
            </chartareas>
        </asp:Chart>
  

Example 1 中的程式碼會指示 Chart 控制產生長條圖的 JPEG 影像，並將其寫入暫存目錄 ~/Temporary/Graph。當控制寫入影像至磁碟後，使用者的瀏覽器將進行檔案的後續要求，並顯示檔案供使用者查看。影像並未安全地寫入磁碟。另外，程式碼假設基礎架構會保護檔案，不受其他未經授權的使用者存取。

在建立包含表單形式的使用者憑證、使用者名稱/密碼組或用戶端憑證的 NSURLCredential 實例時，需要定義持續性屬性。可能的值如下：

-NSURLCredentialPersistenceNone：不應儲存憑證。
-NSURLCredentialPersistenceForSession：只能儲存憑證用於此階段作業。
-NSURLCredentialPersistencePermanent：憑證應儲存在金鑰鏈中。
-NSURLCredentialPersistenceSynchronizable：憑證應永久儲存在金鑰鏈中，並且應分發至以擁有 AppleID 為基礎的其他裝置上。

由於 NSURLCredentialPersistenceSynchronizable 憑證會分發至其他裝置以及 iCloud，因此未完整移除所有位置的憑證可能使憑證遭到洩漏。

範例 1：以下程式碼片段將建立一個可同步處理的憑證，並使用該憑證，然後從本機移除，但無法將其從其他裝置和 iCloud 上移除：

    ...
    // Create the credential
	NSURLCredential *credential = [NSURLCredential credentialWithUser:user password:password persistence:NSURLCredentialPersistenceSynchronizable]; 
    NSURLCredentialStorage *shared = [NSURLCredentialStorage sharedCredentialStorage];
    [shared setDefaultCredential:credential forProtectionSpace:protectionSpace]; 

    // Use the credential as needed
    ...

    // Removes the credential
    [shared removeCredential:credential forProtectionSpace:protectionSpace];
    ...

當私人使用者資訊儲存於未加保護的位置時，就會發生Privacy Violation。
範例 1：以下 XML 包含 plist 檔案中使用者的私人資訊。在其他儲存的值中，MyCreditCard 金鑰會儲存與帳戶相關且由使用者提供的純文字信用卡卡號。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>password</key>
  <string>BASICSECRET</string>
  <key>credentials</key>
  <dict>
          <key>pin</key>
          <string>2345</string>
          <key>MyCreditCard</key>
          <string>1111 11 2321 1112</string>
          <key>MysSn</key>
          <string>1111-22-3333</string>
          <key>ssn</key>
          <string>2345-22-3345</string>
          <key>userid</key>
          <string>12345</string>
  </dict>
</dict>
</plist>

Example 1 中的程式碼在裝置上未加保護的 plist 檔案中儲存來自行動裝置的私人使用者資訊。雖然許多開發者信任 plist 檔案是任何及所有資料的安全儲存位置，但不應對其絕對信賴，特別是關係到隱私問題時，因為 plist 檔案可由擁有裝置的任何人讀取。

隱私資料可以透過多種方式進入到程式中：

- 直接來自於使用者的密碼或個人資訊。

- 應用程式從資料庫或其他資料存放區存取。

- 間接地來自於合作者或者其他第三方。

- 從行動資料儲存區擷取的項目包含：通訊錄、快照、地理位置、組態設定檔案 (包括 plist)、封存 SMS 訊息等。

有時候，未標示為隱私的資料仍有可能在不同的內容中有隱私含意。例如，學生的學號通常不會視為隱私資訊，因為學號中沒有明確和公開的資訊以對應於個別學生的個人資訊。不過，如果學校以學生的身份證字號來產生學號，則此學號應視為隱私資訊。

安全性和隱私似乎時常互相矛盾。從安全的觀點來看，您應該要記錄所有重要的操作，以便於日後辨別所有的異常活動。不過，當其中包含了私人資料時，此種作法將會造成其他風險。

雖然有多種情況會發生隱私資料處理不安全，但常見的風險多是來自盲目的信賴。程式設計師通常會信賴程式執行的作業環境，所以相信將隱私資訊儲存在檔案系統、登錄、plist 內或是其他局部控制的資源中是可以接受的。不過，即使存取特定資源是受限制的，亦不保證應予信賴可以存取該資料的個體。例如，在 2004 年時一位無恥的 AOL 員工將大約 9 千 2 百萬名客戶的私人電子郵件地址賣給了一個透過發送垃圾郵件進行行銷的賭博網站 [1]。

為了應對此類受矚目的資料攻擊事件，隱私資料的收集和管理正日益規範。要求各組織根據其位置、所管理的業務類型，以及其所處理的隱私資訊性質，遵守以下一個或多個聯邦和州的規定：

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

雖已制訂規範，但隱私違反的情況仍持續發生。

已識別的欄位未停用 iOS 的鍵盤快取機制。因此，最近輸入該欄位的任何敏感資訊都會由 iOS 快取，以改善其自動校正功能。

範例 1：輸入到敏感文字欄位的輸入會儲存在系統的鍵盤快取中：

ViewController.h
...

@property (nonatomic, retain) IBOutlet UITextField *ssnField;

...

Example 1 中的程式碼指出，應用程式使用了專門用於收集敏感資訊的輸入控制項。由於 iOS 會快取文字欄位中的輸入以改善其自動校正功能的效能，因此最近在此類輸入控制項中輸入的任何資訊都可能會快取到鍵盤快取檔案中，該檔案會儲存於檔案系統。因為鍵盤快取檔案儲存在裝置上，所以如果裝置遺失，他人可能會將該檔案進行復原，如此一來，就會顯示其中所包含的任何敏感資訊。

私人資料可以透過多種方式進入到程式中：

- 直接來自於使用者的密碼或個人資訊。

- 從應用程式存取資料庫或其他資料儲存。

- 間接地來自於合作者或者第三方。

- 從行動資料商店擷取的項目包含：通訊錄、快照、地理位置、組態設定檔案、封存 SMS 訊息等。

有些資料未標示為私人資料，但仍有可能根據狀況有隱私含意。例如，學生的學號通常不被認為是隱私資訊，因為學號中沒有明確和公開的資訊以對應於個別學生的個人資訊。不過，如果學校以學生的身份證字號來產生學號，則此學號應視為隱私資訊。

安全和隱私似乎時常互相矛盾。從安全的觀點來看，您應該要記錄所有重要的操作，以便於日後辨別所有的異常活動。不過，當其中包含了私人資料時，此種作法將會造成其他風險。

雖然有多種情況會發生隱私資料處理不安全，但常見的風險多是來自盲目的信賴。程式設計師通常會信賴程式執行的作業環境，所以相信將隱私資訊儲存在檔案系統、登錄或是其他局部控制的資源中是可以接受的。不過，即使對特定資源的存取施加限制，並不保證可以存取特定資料的個體是可以信賴的。例如，在 2004 年時一位無恥的 AOL 員工將大約 9 千 2 百萬名客戶的私人電子郵件地址賣給了一個透過發送垃圾郵件進行行銷的賭博網站 [1]。

由於此類受矚目的資料攻擊事件，隱私資料的收集和管理方面的規範日益增加。要求各組織根據其位置、所管理的業務類型，以及其所處理的隱私資訊性質，遵守以下一個或多個聯邦和州的規定：

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

雖已制定規範，但 Privacy Violation 的情況仍持續發生。

已識別的 UIViewController 子類別不會在 iOS 快取螢幕內容之前實作用於隱藏螢幕元素的適當方法。這會將應用程式背景化之前輸入至輸入控制項的任何敏感資訊顯示出來。

範例 1：輸入至 iOS 文字控制項的內容可能會儲存於應用程式背景化 (在應用程式運作時按下「主畫面」按鈕) 時所擷取的螢幕快照中。

ViewController.h
...

@property (nonatomic, retain) IBOutlet UITextField *ssnField;

...

Example 1 中的程式碼指出，應用程式使用了專門用於收集敏感資訊的輸入控制項。由於 iOS 會在應用程式背景化時擷取其使用中檢視的螢幕快照以改善動畫效能，因此背景化事件期間此類輸入控制項中所顯示的任何資訊都可能會被快取到影像中，該影像會儲存於檔案系統。因為這些螢幕快取的螢幕快照儲存在裝置上，所以如果裝置遺失，他人可能會對快照進行復原，如此一來，就會顯示其中所包含的任何敏感資訊。

私人資料可以透過多種方式進入到程式中：

- 直接來自於使用者的密碼或個人資訊。

- 從應用程式存取資料庫或其他資料儲存。

- 間接地來自於合作者或者第三方。

- 從行動資料儲存區擷取的項目包含：通訊錄、快照、地理位置、組態檔、封存 SMS 訊息等。

有些資料未標示為私人資料，但仍有可能根據狀況有隱私含意。例如，學生的學號通常不被認為是隱私資訊，因為學號中沒有明確和公開的資訊以對應於個別學生的個人資訊。不過，如果學校以學生的身份證字號來產生學號，則此學號應視為隱私資訊。

安全和隱私似乎時常互相矛盾。從安全的觀點來看，您應該要記錄所有重要的操作，以便於日後辨別所有的異常活動。不過，當其中包含了私人資料時，此種作法將會造成其他風險。

雖然有多種情況會發生隱私資料處理不安全，但常見的風險多是來自盲目的信賴。程式設計師通常會信賴程式執行的作業環境，所以相信將隱私資訊儲存在檔案系統、登錄或是其他局部控制的資源中是可以接受的。不過，即使對特定資源的存取施加限制，並不保證可以存取特定資料的個體是可以信賴的。例如，在 2004 年時一位無恥的 AOL 員工將大約 9 千 2 百萬名客戶的私人電子郵件地址賣給了一個透過發送垃圾郵件進行行銷的賭博網站 [1]。

由於此類受矚目的資料攻擊事件，隱私資料的收集和管理方面的規範日益增加。要求各組織根據其位置、所管理的業務類型，以及其所處理的隱私資訊性質，遵守以下一個或多個聯邦和州的規定：

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

雖已制定規範，但 Privacy Violation 的情況仍持續發生。

Documents 目錄用於儲存非暫時性應用程式資料，例如允許應用程式以離線模式執行的使用者建立的內容或本機資訊。如果在應用程式的 Info.plist 檔案中設定了 UIFileSharingEnabled，則此處的檔案將可以透過 iTunes 存取。將敏感資料寫入 Documents 目錄時，該資料可能會暴露於未加密的備份或 iTunes 介面。

範例 1：以下程式碼片段會將使用者密碼以純文字形式寫入 Documents 目錄：

    ...
    NSString *docsDirectory = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
    NSString *passwd_path = [docsDirectory stringByAppendingPathComponent:@"passwords.txt"];

    NSString *password = [user password];
    [password writeToFile:passwd_path atomically:YES encoding:NSUTF8StringEncoding error:nil];
    ...

某些收集敏感資訊的 API 可能會透過將敏感資訊回傳給使用者而錯誤處理該資訊。

範例 1：以下程式碼示範了密碼收回 (callback) 物件的個體化，這個物件不會在使用者依輸入提示輸入密碼時隱藏使用者的密碼：

PasswordCallback pc = new PasswordCallback("Please enter your password: ", true);

由於 Example 1 中的 pc 在其第二個參數 onEcho 設為 true 的情況下進行個體化，因此當使用者依「請輸入密碼:」提示輸入密碼時，將不會隱藏其密碼。

在以下情況會發生隱私違反情況：

1.私人使用者資訊進入程式。
2.資料寫入到外部位置，例如主控台、檔案系統或網路。

範例 1：以下易受攻擊的程式碼包含一個組態陳述式，其允許記錄未經過模糊處理的密碼「admin_password」。

from oslo_config import cfg
 ...
opts = [
  cfg.StrOpt('admin_password',secret=False,
               help="User's password")]
 ...              
grp = cfg.OptGroup('mygroup')
cfg.CONF.register_opts(opts, group=grp)
 ...
logger.warning("Adding %s" % cfg.CONF.mygroup.admin_password)

Example 1 中的程式碼將 admin_password 以純文字 (未經過模糊處理) 寫入記錄輸出，因為 secret 的值設定為 False。雖然許多的開發人員相信事件記錄為儲存資料的安全位置，但不應對其絕對信賴，特別是關係到隱私問題時。

隱私資料可以透過多種方式進入到程式中：

- 直接來自於使用者的密碼或個人資訊

- 應用程式從資料庫或其他資料存放區存取

- 間接地來自於合作者或者其他第三方

有時候，未標示為隱私的資料仍有可能在不同的內容中有隱私含意。例如，學生的學號通常不會視為隱私資訊，因為學號中沒有明確和公開的資訊以對應於個別學生的個人資訊。不過，如果學校以學生的身份證字號來產生學號，則此學號應視為隱私資訊。

安全性和隱私似乎時常互相矛盾。從安全的觀點來看，您應該要記錄所有重要的操作，以便於日後辨別所有的異常活動。不過，當其中包含了私人資料時，此種作法將會造成風險。

雖然有多種情況會發生隱私資料處理不安全，但常見的風險多是來自盲目的信賴。程式設計師通常會信賴程式執行的作業環境，所以相信將隱私資訊儲存在檔案系統、登錄或是其他局部控制的資源中是可以接受的。但即使限制特定資源的存取權，也並不保證可以信任有存取權的個人。例如，在 2004 年時一位無恥的 AOL 員工將大約 9 千 2 百萬名客戶的私人電子郵件地址賣給了一個透過發送垃圾郵件進行行銷的賭博網站 [1]。

為了應對此類受矚目的資料攻擊事件，隱私資料的收集和管理正日益規範。要求各組織根據其位置、所管理的業務類型，以及其所處理的隱私資訊性質，遵守以下一個或多個聯邦和州的規定：

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

雖已制訂規範，但隱私違反的情況仍持續發生。

攻擊者可能透過以下方式來利用未經檢查之權限中的弱點：

1. 資料從不可信賴的來源進入應用程式。

2. 資料用於表示使用者或群組識別碼、權限清單或是套用權限的資源，且事先未進行任何例行性檢查。應用程式接著會使用這些未經檢查的資料來編輯權限設定。

此權限具有「危險」保護層級。被指定為危險的權限意味著使用者資料隱私或裝置操作的風險增加。在這種情況下，存取體能活動資訊會對使用者隱私和人身安全構成威脅。必須非常謹慎地管理需要使用者體能活動資訊存取權的應用程式。

範例 1：AndroidManifest.xml 的<uses-permission .../> 元素宣告使用 ACTIVITY_RECOGNITION 權限，這讓應用程式能辨識使用者的體能活動。

 <uses-permission android:name="android.permission.ACTIVITY_RECOGNITION"/> 

此權限具有「危險」保護層級。被指定為危險的權限意味著使用者資料隱私或裝置操作的風險增加。在這種情況下，存取使用者的行事曆可能會對使用者隱私和人身安全構成威脅。應用程式必須將行事曆資料視為敏感資料，並極其謹慎地管理它以維護隱私。

範例 1：AndroidManifest.xml 的<uses-permission .../> 元素宣告使用 READ_CALENDAR 權限，這讓應用程式能讀取使用者的行事曆資料。

 <uses-permission android:name="android.permission.READ_CALENDAR"/> 

範例 2：AndroidManifest.xml 的<uses-permission .../> 元素宣告使用 WRITE_CALENDAR 權限，這讓應用程式能寫入使用者的行事曆資料。

 <uses-permission android:name="android.permission.WRITE_CALENDAR"/> 

此權限具有「危險」保護層級。被指定為危險的權限意味著使用者資料隱私或裝置操作的風險增加。在這種情況下，存取通話記錄會對使用者隱私和人身安全構成威脅。必須非常謹慎地管理需要通話記錄存取權的應用程式。

範例 1：AndroidManifest.xml 的<uses-permission .../> 元素宣告使用 READ_CALL_LOG 權限，這讓應用程式能讀取使用者的通話記錄。

 <uses-permission android:name="android.permission.READ_CALL_LOG"/> 

範例 2：AndroidManifest.xml 的<uses-permission .../> 元素宣告使用 WRITE_CALL_LOG 權限，這讓應用程式能寫入使用者的通話記錄。

 <uses-permission android:name="android.permission.WRITE_CALL_LOG"/> 

此權限具有「危險」保護層級。被指定為危險的權限意味著使用者資料隱私或裝置操作的風險增加。在這種情況下，存取相機可能會對使用者隱私和人身安全構成威脅。必須非常謹慎地管理需要相機存取權的應用程式。

範例 1：AndroidManifest.xml 的<uses-permission .../> 元素宣告使用 CAMERA 權限，這讓應用程式能存取裝置的相機。

 <uses-permission android:name="android.permission.CAMERA"/> 

此權限具有「危險」保護層級。被指定為危險的權限意味著使用者資料隱私或裝置操作的風險增加。在這種情況下，存取聯絡人資訊會對使用者隱私和人身安全構成威脅。應用程式必須將聯絡人資料視為敏感資料，並極其謹慎地管理它。

範例 1：AndroidManifest.xml 的<uses-permission .../> 元素宣告使用 READ_CONTACTS 權限，這讓應用程式能讀取使用者的聯絡人資料。

 <uses-permission android:name="android.permission.READ_CONTACTS"/> 

範例 2：AndroidManifest.xml 的<uses-permission .../> 元素宣告使用 WRITE_CONTACTS 權限，這讓應用程式能寫入使用者的聯絡人資料。

 <uses-permission android:name="android.permission.WRITE_CONTACTS"/> 

範例 3：AndroidManifest.xml 的<uses-permission .../> 元素宣告使用 GET_ACCOUNTS 權限，這讓應用程式能存取使用者的電子郵件以及儲存在「帳戶管理員」中的線上帳戶。使用此權限可以存取敏感資料，例如帳戶 ID、電子郵件地址和電話號碼。

 <uses-permission android:name="android.permission.GET_ACCOUNTS"/> 

任何程式和使用者皆可讀寫已寫入外部儲存裝置的檔案。程式不得寫入個人身份等敏感資訊至外部儲存裝置。透過 USB 將 Android 裝置連接到電腦或其他裝置，就會啟用 USB 大量儲存模式。在此模式中，您可以讀取並修改所有寫入外部儲存裝置的檔案。此外，就算您解除安裝寫入檔案的應用程式，檔案仍然會保留在外部儲存裝置中，因而更可能洩露儲存在裝置中的敏感資訊。

範例 1：AndroidManifest.xml 的 <uses-permission .../> 元素宣告使用 WRITE_EXTERNAL_STORAGE 權限，這讓應用程式能寫入外部儲存裝置。

 <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> 

範例 2：AndroidManifest.xml 的 <uses-permission .../> 元素宣告使用 READ_EXTERNAL_STORAGE 權限，這讓應用程式能讀取外部儲存裝置。

 <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>