安全性
以下指南包含您在開發 Cordova 應用程式時應考慮的一些安全性最佳實務。請注意，安全性是一個非常複雜的主題，因此本指南並非詳盡無遺。如果您認為可以為本指南做出貢獻，請隨時在 Cordova 的 cordova-docs 儲存庫中建立提取請求。本指南旨在適用於一般的 Cordova 開發（所有平台），但會註明特殊的平台特定考量。
本指南討論以下主題
- 允許清單
- Iframe 和回呼 ID 機制
- 憑證固定
- 自我簽署憑證
- 加密儲存
- 一般提示
- 建議文章和其他資源
允許清單
預設情況下，應用程式的導覽不受限制。建議將導覽限制為僅信任的網域。閱讀 允許清單指南以了解更多資訊
Iframe 和回呼 ID 機制
如果內容在 iframe 中從允許清單中的網域提供，該網域將有權存取原生 Cordova 橋接器。這表示如果您允許第三方廣告網路並透過 iframe 提供這些廣告，則惡意廣告可能會從 iframe 中跳脫並執行惡意操作。因此，除非您控制託管 iframe 內容的伺服器，否則通常不應使用 iframe。另請注意，有第三方外掛程式可用於支援廣告網路。請注意，此聲明不適用於 iOS，iOS 會攔截所有內容，包括 iframe 連線。
憑證固定
Cordova 不支援真正的憑證固定。這的主要障礙是 Android 中缺乏用於攔截 SSL 連線以執行伺服器憑證檢查的原生 API。（雖然可以在 Android 中使用 JSSE 在 Java 中進行憑證固定，但 Android 上的 webview 是用 C++ 編寫的，伺服器連線由 webview 為您處理，因此無法在那裡使用 Java 和 JSSE。）由於 Apache Cordova 的目的是在多個平台提供一致的 API，因此在主要平台中沒有此功能會破壞一致性。
有些方法可以近似憑證固定，例如在應用程式啟動時或應用程式生命週期的其他時間檢查伺服器的公開金鑰（指紋）是否為預期值。有第三方外掛程式可用於 Cordova 來執行此操作。但是，這與真正的憑證固定不同，後者會在每次連線到伺服器時自動驗證預期值。
也有一些外掛程式可以為某些平台執行真正的憑證固定，前提是您的應用程式可以使用外掛程式執行其所有網路請求（即：沒有傳統的 XHR/AJAX 請求等）。
使用 TLS/SSL
如果您的應用程式與外部伺服器通訊，則應使用現代加密標準進行通訊。盡可能使用 https 通訊協定。
Let's Encrypt 是由非營利組織 網際網路安全研究小組提供的免費、自動化且開放的憑證授權單位。Let's Encrypt 將提供免費的標準憑證，這對於大多數開發人員來說已經足夠。企業組織可能仍然希望使用提供更進階功能的傳統憑證授權單位，例如 組織驗證憑證。
隨著時間的推移，與時俱進地了解安全性標準也很重要。今天可以接受的 SSL/TLS 設定在未來幾年可能無法接受。應定期使用工具來測試您的憑證和 SSL/TLS 設定。SSL Labs 是由 Qualys, Inc. 提供的免費線上服務，用於測試您伺服器的 SSL/TLS 設定和加密強度，以及支援的平台。
自我簽署憑證
不建議在您的伺服器上使用自我簽署憑證。如果您需要 SSL，強烈建議您的伺服器擁有由知名的 CA（憑證授權單位）正確簽署的憑證。無法進行真正的憑證固定使得這一點很重要。
原因是接受自我簽署憑證會繞過憑證鏈驗證，這會允許任何伺服器憑證被裝置視為有效。這會使通訊暴露於中間人攻擊。駭客不僅可以輕鬆攔截和讀取裝置和伺服器之間的所有通訊，還可以修改通訊。裝置永遠不會知道正在發生這種情況，因為它不會驗證伺服器的憑證是否由受信任的 CA 簽署。裝置無法證明伺服器是它所期望的伺服器。由於中間人攻擊很容易進行，因此接受自我簽署憑證僅比在不受信任的網路上執行 http 而不是 https 稍微好一些。是的，流量會被加密，但它可能會使用中間人的金鑰加密，因此中間人可以存取所有內容，因此加密除了對被動觀察者之外，毫無用處。使用者相信 SSL 是安全的，而這會故意使其不安全，因此 SSL 的使用會產生誤導。
如果應用程式僅在受信任的網路（例如內部公司網路）中使用。可以使用自我簽署憑證，但是公用憑證應預先安裝在將執行該應用程式的裝置上。受信任的第三方憑證授權單位始終是首選。
此處描述的原則並非 Apache Cordova 專屬，它們適用於所有用戶端-伺服器通訊。
在 Android 上執行 Cordova 時，在應用程式資訊清單中使用 android:debuggable="true" 將允許 SSL 錯誤，例如自我簽署憑證上的憑證鏈驗證錯誤。因此，您可以在此設定中使用自我簽署憑證，但是當您的應用程式在生產環境中時，不應使用此設定。它僅用於應用程式開發期間。
加密儲存
(待定)
一般提示
不要使用 Android Gingerbread！
- 將您的 min-target-sdk 層級設定為高於 10。API 10 是 Gingerbread，而 Gingerbread 不再受 Google 或裝置製造商支援，因此 Cordova 團隊不建議使用。
- Gingerbread 已被證明是不安全的，並且是最受攻擊的行動作業系統之一 https://www.mobilemag.com/2012/11/06/andriod-2-3-gingerbread-security/。
- Android 上的允許清單不適用於 Gingerbread 或更低版本。這表示攻擊者可以在 iframe 中載入惡意程式碼，然後該程式碼將有權存取所有 Cordova API，並可以使用該存取權來竊取個人資料、將簡訊傳送到加值號碼，以及執行其他惡意行為。
使用 InAppBrowser 開啟外部連結
- 在開啟任何外部網站的連結時，請使用 InAppBrowser。這比允許列出網域名稱並直接在您的應用程式中包含內容安全得多，因為 InAppBrowser 將使用原生瀏覽器的安全性功能，並且不會讓網站存取您的 Cordova 環境。即使您信任第三方網站並直接在您的應用程式中包含它，該第三方網站也可能會連結到惡意網路內容。
驗證所有使用者輸入
- 始終驗證您的應用程式接受的任何和所有輸入。這包括使用者名稱、密碼、日期、上傳的媒體等。因為攻擊者可能會操縱您的 HTML 和 JS 資產（透過反編譯您的應用程式或使用 chrome://inspect 等偵錯工具），因此也應在您的伺服器上執行此驗證，尤其是在將資料交給任何後端服務之前。
- 應驗證資料的其他來源：使用者文件、聯絡人、推播通知
不要快取敏感資料
- 如果使用者名稱、密碼、地理定位資訊和其他敏感資料被快取，則可能會稍後被未經授權的使用者或應用程式檢索。
除非您知道自己在做什麼，否則不要使用 eval()
- JavaScript 函數 eval() 有很長的被濫用歷史。不正確地使用它可能會使您的程式碼容易受到注入攻擊、偵錯困難和程式碼執行速度較慢。
不要假設您的原始碼是安全的
- 由於 Cordova 應用程式是從 HTML 和 JavaScript 資產建立的，這些資產會封裝在原生容器中，因此您不應認為您的程式碼是安全的。可以對 Cordova 應用程式進行逆向工程。