許可證： 下一個或多個參與者授權合約許可向阿帕奇軟體基金會 (ASF)。 請參閱分散式與此工作為版權的擁有權有關的其他資訊的通知檔。 ASF 許可證，此檔到你根據 Apache 許可證，2.0 版 （“許可證”） ；您不可能使用此檔除了符合許可證。 您可能會獲得在許可證的副本
HTTP://www.apache.org/licenses/LICENSE-2.0 除非適用的法律要求或書面同意，否則按照該許可證分發的軟體分發上"按原樣"的基礎，而不擔保或條件的任何種類的明示或暗示。 請參閱許可證規定的許可權和限制的特定語言
以下指南包括開發科爾多瓦的應用程式時，應考慮一些安全最佳做法。 請務必注意安全是一個非常複雜的主題，因此本指南不是詳盡無遺。 如果你認為你可以貢獻本指南，請隨時在科爾多瓦的 bug 追蹤器下“文檔”中檔的問題。 本指南旨在適用于一般科爾多瓦發展 （所有平臺），但將指出特定于平臺的特殊注意事項。
閱讀和理解，白名單指南
預設情況下，白名單上新創建的應用程式將允許通過的每個域訪問 <access> 標記： <access origin="*"> 如果您想要針對白名單中，評估的網路請求，則它是重要的是要改變這和只允許，您需要訪問的域。 這可以通過編輯應用程式級設定檔位於： {project}/config.xml （最近的專案） 或 {project}/www/config.xml （舊專案）
Android 的白名單中科爾多瓦 2.9.x 被認為安全，然而，它被發現是否 foo.com 列入白名單中，foo.com.evil.com 將能夠通過白名單測試。 這固定在科爾多瓦 3.x。
域白名單不工作在 Android API 10 和下面，和 WP8 的 iframe 和用戶端代碼。 這意味著攻擊者可以載入任何域中 iframe 和科爾多瓦 JavaScript 物件和相應的本機 JAVA 物件，可以直接存取該 iframe 內的頁面上的任何腳本。 構建這些平臺的應用程式時，應考慮到這種情況。 在實踐中這意味著確保目標高於 10，Android API 和如果可能不使用 iframe 載入外部內容-使用 inAppBrowser 外掛程式或其他協力廠商外掛程式。
Android 系統，如科爾多瓦 3.6.0，它現在有必要到白名單中 Url 在您的應用程式，如果您的應用程式生成這些 Url 的連結。 如果你的應用程式將生成 tel: ， geo: ， sms: ， intent: 或類似的 Url，或提供您希望在使用者的瀏覽器中，打開，然後你將需要更新您的白名單中的外部內容的連結。 請參閱白名單指南的詳細資訊。
如果內容提供在 iframe 從白名單中的域中，該域將可以訪問到本機的科爾多瓦橋。 這意味著，如果白名單中的協力廠商廣告網路和服務通過 iframe 的那些廣告，它有可能是惡意的廣告將能夠打破 iframe 並執行惡意操作。 因此，您通常不應使用 iframe 除非你控制的伺服器的承載的 iframe 內容。 此外請注意有協力廠商外掛程式提供支援的廣告網路。 注意此語句不是真正的 iOS，攔截一切包括 iframe 的連接。
科爾多瓦不支援真正的證書固定。 對此的一個主要障礙是證書的缺乏在 android 系統中的本機 Api 攔截 SSL 連線執行檢查伺服器。 （雖然有可能要做證書寄于 Android 在 JAVA 中使用 JSSE，c + +，編寫在 android 系統上的 web 視圖和 web 視圖為你處理伺服器連接，所以它是不可能有使用 JAVA 和 JSSE)。因為 Apache 科爾多瓦要跨多個平臺提供一致的 Api，不具有能力的一個主要平臺打破了這種一致性。
有種方法近似證書鎖定，如檢查伺服器的公開金鑰 （指紋） 預期值，當您的應用程式啟動時或在其他不同的時間，在您的應用程式的存留期內。 有協力廠商外掛程式可供能不能做到的科爾多瓦。 然而，這不是真實證書將鎖定，將自動驗證每個連接到伺服器上的預期值相同。
不建議在您的伺服器上使用自簽名的證書。 如果你渴望 SSL，那麼強烈建議您的伺服器具有已正確地簽署了著名的 CA （憑證授權單位） 的證書。 不能做真正的證書寄使這一重要。
原因是接受自簽名的證書繞過憑證連結驗證，它允許任何伺服器憑證才被視為有效的設備。 這將打開溝通的人在中間的攻擊。 它變得非常容易為駭客不僅攔截並讀取在設備和伺服器之間的所有通信，但也要修改通信。 設備永遠不會知道這種情況發生，因為它不會驗證服務器的證書由受信任的 CA 簽署。 該設備具有伺服器是它期望的人沒有證據證明。 因為做的人在中間攻擊的易用性，接受自簽名的證書才略微比只在不受信任的網路上運行而不是 HTTPs 的 HTTP。 是的交通將會被加密，但它可能會用金鑰加密從一個男人-中--中間，所以攔截中可以訪問的一切，所以加密是無用除了對被動的觀察員。 使用者信任 SSL 以是安全的和這將故意做出它不安全的所以，SSL 利用成為具誤導性。 如果這將受信任的網路上使用 （即，您是完全控制企業內部），然後仍不建議使用自簽名的證書。 在受信任的網路中的兩項建議是因為網路本身是受信任的只是使用 HTTP 或獲取由受信任的 CA （不自簽名） 簽署的證書。 網路是受信任的或者它不是。
在這裡所描述的原則不是特定于 Apache 科爾多瓦，它們適用于所有用戶端-伺服器通信。
當運行時科爾多瓦在 android 系統上，使用 android:debuggable="true" 應用程式中清單將允許 SSL 錯誤，例如憑證連結驗證錯誤的自簽章憑證。 所以您可以在此配置中，使用自簽名的證書，但這不是一種配置，您的應用程式是在生產時，應使用。 意思是，只有在應用程式開發期間使用。
（TBD）