包含另外一個網站中可執行的內容是有風險的。這樣會導致您網站的安全性與另一個網站息息相關。

範例 1：請考慮以下 script 標籤。

  <script src="http://www.example.com/js/fancyWidget.js"></script>

如果這個標籤出現在 www.example.com 以外的網站上，則該網站依賴 www.example.com 提供正確且無惡意的程式碼。如果攻擊者能危害 www.example.com，他們就能修改 fancyWidget.js 的內容來破壞網站的安全性。例如，他們可以新增程式碼至 fancyWidget.js 來竊取使用者的機密資料。

程式設計師通常會信任隱藏欄位的內容，預期使用者無法檢視或竄改他們的內容。攻擊者將會推翻這些假設。他們會檢查寫入隱藏欄位的值並加以修改，或以攻擊資料取代這些內容。

範例 1：

  Hidden hidden = new Hidden(element);

若隱藏欄位具有敏感資訊，該資訊的快取方式將與其他的頁面相同。這可能會導致敏感資訊在使用者不知情的狀況下貯存至瀏覽器快取中。

HTML5 的功能之一便是在用戶端 SQL 資料庫儲存資料的能力。開始從資料庫寫入和讀取時，最重要的資訊就是其名稱。因此，各使用者的資料庫名稱必須為唯一字串。如果資料庫名稱很容易猜中，那麼未授權的對象 (如其他使用者) 便可能偷取敏感資料或毀損資料庫項目。
範例 1：下列程式碼使用了易於猜中的資料庫名稱：

...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...

此程式碼將成功執行，但能夠猜到資料庫名稱為 'mydb' 的人都可以加以存取。

內容安全性原則 (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。

每個指令都使用來源清單做為一個值，此值指定針對該指令所涵蓋的功能，網站可存取的網域。開發人員可使用萬用字元 * 來指示所有或部分來源。所有指令都不是強制性的。瀏覽器將允許未列示指令的所有來源，或從選用的 default-src 指令衍生值。此外，此表頭的規格隨著時間的推移而不斷演變。在第 23 版之前的 Firefox 和第 10 版之前的 IE 中，其實做為 X-Content-Security-Policy，而在第 25 版之前的 Chrome 中，其實做為 X-Webkit-CSP。兩個名稱都已棄用，取代為現在的標準名稱 Content Security Policy。鑒於指令的數目、兩個棄用的替代名稱，以及對待多次出現之同一表頭和單一表頭中重複指令的方式，開發人員很可能會錯誤地配置此表頭。

考慮以下配置錯誤的情況：

- 具有 unsafe-inline 或 unsafe-eval 的指令違背了 CSP 的目的。
- 已設定 script-src 指令，但未配置任何 Script nonce。
- 已設定 frame-src，但未配置任何 sandbox。
- 在同一回應中允許使用此表頭的多個實例。開發團隊和安全性團隊可能都會設定表頭，但其中一個可能會使用棄用的名稱之一。雖然在不存在具有最新名稱 (即，內容安全性原則) 的表頭時會接受棄用的表頭，但如果存在具有 content-security-header 名稱的原則，便會忽略棄用的表頭。舊版本只理解棄用的名稱，因此，要實現預期支援，回應必須包含具有這三個名稱的相同原則。
- 如果在表頭的同一實例中重複出現某個指令，則會忽略之後出現的所有該指令。

範例 1：以下 django-csp 配置使用不安全的指令 unsafe-inline 和 unsafe-eval，以便允許內嵌 Script 和程式碼評估：

...
MIDDLEWARE = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

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

依預設，Spring Security 和其他架構並不新增內容安全性原則標頭。Web 應用程式作者必須宣告一或多個安全性原則，以強制執行或監視受保護的資源，進而從這額外一層的安全性受益。

允許將您的網站新增到框架會引起安全問題。例如，這可能導致點擊劫持弱點，或允許不希望的跨框架通訊。

依預設，Spring Security 之類的架構包含 X-Frame-Options 標頭，以指示瀏覽器是否應對應用程式進行框架處理。停用或未設定此標頭會導致跨框架相關弱點。

範例 1：以下程式碼會將受 Spring Security 保護的應用程式設定為停用 X-Frame-Options 標頭：

	<http auto-config="true">
        ...
        <headers>
            ...
            <frame-options disabled="true"/>
        </headers>
	</http>

內容安全性原則 (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);
...