セキュリティ

以下のガイドには、Cordovaアプリケーションを開発する際に考慮すべきセキュリティのベストプラクティスが含まれています。セキュリティは非常に複雑なトピックであるため、このガイドは網羅的なものではないことに注意してください。このガイドに貢献できるとお考えの方は、Cordovaのcordova-docsリポジトリにプルリクエストを作成してください。このガイドは、一般的なCordova開発（すべてのプラットフォーム）に適用できるように設計されていますが、プラットフォーム固有の特別な考慮事項も記載されています。

このガイドでは、以下のトピックについて説明します。

許可リスト
IframeとコールバックIDメカニズム
証明書のピン留め
自己署名証明書
暗号化されたストレージ
一般的なヒント
推奨記事とその他のリソース

許可リスト

デフォルトでは、アプリのナビゲーションは無制限です。信頼できるドメインのみにナビゲーションを制限することをお勧めします。許可リストガイドを読んで詳細をご覧ください。

IframeとコールバックIDメカニズム

許可リストに登録されたドメインからiframeでコンテンツが提供される場合、そのドメインはネイティブCordovaブリッジにアクセスできます。これは、サードパーティの広告ネットワークを許可し、iframeを介してそれらの広告を提供する場合、悪意のある広告がiframeから抜け出して悪意のある行為を実行できる可能性があることを意味します。このため、iframeコンテンツをホストするサーバーを制御していない限り、一般的にiframeを使用しないでください。また、広告ネットワークをサポートするサードパーティのプラグインが利用可能です。この記述は、iframe接続を含むすべてをインターセプトするiOSには当てはまりません。

証明書のピン留め

Cordovaは真の証明書ピン留めをサポートしていません。これに対する主な障壁は、サーバーの証明書のチェックを実行するためにSSL接続をインターセプトするためのネイティブAPIがAndroidにないことです。（JSSEを使用してJavaでAndroidで証明書ピン留めを行うことは可能ですが、AndroidのwebviewはC ++で記述されており、サーバー接続はwebviewによって処理されるため、JavaとJSSEをそこで使用することはできません。）Apache Cordovaは、複数のプラットフォームで一貫したAPIを提供することを目的としているため、主要なプラットフォームで機能がないと、その一貫性が損なわれます。

証明書ピン留めを近似する方法があります。たとえば、アプリケーションの起動時またはアプリケーションのライフタイム中の他のさまざまな時間に、サーバーの公開鍵（フィンガープリント）が予期される値であることを確認します。Cordovaには、これを実行できるサードパーティのプラグインが用意されています。ただし、これは、サーバーへのすべての接続で予期される値を自動的に検証する真の証明書ピン留めとは異なります。

アプリがプラグインを使用してすべてのネットワークリクエストを実行できる場合（つまり、従来のXHR / AJAXリクエストなどがない場合）、一部のプラットフォームで真の証明書ピン留めを実行できるプラグインもあります。

TLS / SSLの使用

アプリが外部サーバーと通信する場合、最新の暗号化規格を使用して通信する必要があります。可能な限り`https`プロトコルを使用してください。

Let's Encryptは、非営利団体Internet Security Research Groupが提供する無料の自動化されたオープン証明機関です。Let's Encryptは無料の標準証明書を提供します。これはほとんどの開発者にとって十分です。企業組織は、組織検証証明書などのより高度な機能を提供する従来の証明機関を引き続き使用することをお勧めします。

セキュリティ標準が時間の経過とともに変化するため、セキュリティ標準の最新の状態を維持することも重要です。現在許容されるSSL / TLS構成は、将来許容されない可能性があります。証明書とSSL / TLS構成をテストするためのツールを定期的に使用する必要があります。SSL Labsは、Qualys、Incが提供する無料のオンラインサービスであり、サーバーのSSL / TLS構成と暗号化強度、およびサポートされているプラットフォームをテストします。

自己署名証明書

サーバーで自己署名証明書を使用することはお勧めしません。SSLが必要な場合は、サーバーに、よく知られているCA（認証機関）によって適切に署名された証明書があることを強くお勧めします。真の証明書ピン留めができないため、これは重要です。

理由は、自己署名証明書を受け入れると、証明書チェーンの検証がバイパスされるため、デバイスによってすべてのサーバー証明書が有効と見なされるためです。これにより、man-in-the-middle攻撃への通信が開かれます。ハッカーは、デバイスとサーバー間のすべての通信を傍受して読み取るだけでなく、通信を変更することも非常に簡単になります。デバイスは、サーバーの証明書が信頼できるCAによって署名されていることを検証しないため、これが発生していることを認識しません。デバイスには、サーバーが期待どおりであるという証拠がありません。man-in-the-middle攻撃の実行が容易であるため、自己署名証明書を受け入れることは、信頼できないネットワークでhttpsの代わりにhttpを実行するよりもわずかに優れているだけです。はい、トラフィックは暗号化されますが、man-in-the-middleのキーで暗号化される可能性があるため、man-in-the-middleはすべてにアクセスできるため、暗号化は受動的なオブザーバーを除いて役に立ちません。ユーザーはSSLが安全であると信頼しており、これは意図的に安全性を低下させるため、SSLの使用は誤解を招くものになります。

アプリケーションが社内ネットワークなどの信頼できるネットワーク内でのみ使用される場合。自己署名証明書を使用することは許容される場合がありますが、公開証明書は、アプリケーションを実行するデバイスにプリインストールする必要があります。信頼できるサードパーティの認証機関が常に推奨されます。

ここで説明する原則はApache Cordovaに固有のものではなく、すべてのクライアントサーバー通信に適用されます。

AndroidでCordovaを実行する場合、アプリケーションマニフェストで`android：debuggable = "true" `を使用すると、自己署名証明書の証明書チェーン検証エラーなどのSSLエラーが発生します。したがって、この構成で自己署名証明書を使用できますが、これは、アプリケーションが運用環境にある場合に使用する必要がある構成ではありません。アプリケーション開発中にのみ使用することを目的としています。

暗号化されたストレージ

（未定）

一般的なヒント

Android Gingerbreadを使用しないでください！

min-target-sdkレベルを10より高く設定します。API 10はGingerbreadであり、GingerbreadはGoogleまたはデバイスメーカーによってサポートされなくなりました。そのため、Cordovaチームは推奨していません。
Gingerbreadは安全ではなく、最も標的にされたモバイルOSの1つであることが示されていますhttps://www.mobilemag.com/2012/11/06/andriod-2-3-gingerbread-security/。
Androidの許可リストは、Gingerbread以下では機能しません。これは、攻撃者が悪意のあるコードをiframeにロードできることを意味します。iframeはすべてのCordova APIにアクセスできるようになり、そのアクセスを使用して個人データを盗んだり、プレミアムレート番号にSMSメッセージを送信したり、その他の悪意のある行為を実行したりする可能性があります。

外部リンクにはアプリ内ブラウザを使用する

外部のWebサイトへのリンクを開くときは、アプリ内ブラウザを使用してください。アプリ内ブラウザはネイティブブラウザのセキュリティ機能を使用し、WebサイトにCordova環境へのアクセスを許可しないため、これはドメイン名を許可リストに登録してコンテンツをアプリケーションに直接含めるよりもはるかに安全です。サードパーティのWebサイトを信頼してアプリケーションに直接含めた場合でも、そのサードパーティのWebサイトが悪意のあるWebコンテンツにリンクする可能性があります。

すべてのユーザー入力を検証する

アプリケーションが受け入れるすべての入力を常に検証します。これには、ユーザー名、パスワード、日付、アップロードされたメディアなどが含まれます。攻撃者はHTMLおよびJSアセットを操作する可能性があるため（アプリケーションを逆コンパイルするか、chrome：// inspectなどのデバッグツールを使用する）、この検証はサーバーでも実行する必要があります。特に、バックエンドサービスにデータを渡す前。
データを検証する必要があるその他のソース：ユーザー文書、連絡先、プッシュ通知

機密データをキャッシュしない

ユーザー名、パスワード、ジオロケーション情報、およびその他の機密データがキャッシュされている場合、権限のないユーザーまたはアプリケーションによって後で取得される可能性があります。

何をしているのかわからない限り、eval（）を使用しないでください

JavaScript関数eval（）には、悪用されてきた長い歴史があります。誤って使用すると、コードがインジェクション攻撃、デバッグの困難さ、コード実行の遅延に対して開かれる可能性があります。

ソースコードが安全であると想定しないでください

Cordovaアプリケーションは、ネイティブコンテナにパッケージ化されたHTMLおよびJavaScriptアセットから構築されているため、コードを安全とは見なさないでください。Cordovaアプリケーションをリバースエンジニアリングすることは可能です。