これが既に質問され回答されている場合はお詫びします私はたくさん見回しましたが、私が求めているものを正確に見つけていません。
-
http://example.com/ にある私のWebアプリが http://api.example.com/ にあるドキュメント化されていないプライベートWeb APIを使用してデータをフェッチするとします。 XHRまたはJSONP経由。
また、このWebアプリは匿名であると仮定します—ユーザーのログインは必要ありません。
クライアントとサーバーの間には通信があるため、誰でもFiddlerなどを開いて、正確な要求と応答を確認できます。クライアント側のJSコードの検査は言うまでもありません。
このような場合、非Webで誰かがあなたのAPIを使用するのをどのように防ぐことができますか?クライアントアプリ?例えば。 iPhoneアプリ、またはサーバー側。
私の理解では、ポイント#2はOAuthなどのオプションを削除し、ポイント#3はオプションを削除します。 APIキーまたはSSL。
最初の読み込み時にページに挿入される時間ベースのトークンやシークレットソルトのようなものについて考えましたが、iPhoneアプリはAPIリクエストを行う前にWebページを簡単にひそかに読み込むことができます。
では、単純な難読化以外の方法はありますか—隠蔽によるセキュリティ?
-
それがすべて抽象的すぎる場合は、簡単な例を次に示します。
Google.comは、非公開で文書化されていないいくつかのAPIを介してオートコンプリートデータをフェッチしますが、Web上で開きます。 iPhoneアプリで使用できないようにするにはどうすればよいですか?
クライアントコードのコピーやネットワークトラフィックの再生を阻止することはできません。
同じOriginポリシー のおかげで、他のWebアプリはクライアントからAPIにアクセスできません。サーバー経由でリクエストをプロキシする必要があります。つまり、これらのリクエストは、一時的にブラックリストに登録できる、簡単に識別できる少数のIPアドレスから送信されます。
デスクトップアプリとモバイルアプリについては、できることはあまりありません。私のアドバイスは、問題になるまで心配しないことです。
そうは言っても、準備していても害はありません。費用のかかる法廷闘争を避けたい場合、できることの1つは、APIメソッドのシグネチャを時々変更することです。リーチングアプリは修正できますが、その評判は着実に低下します。
認証は、APIの悪用を防止するものでもありません。クライアントがシステムで正しく認証できる限り、クライアントは自分が選択した任意のクライアントを使用できます。クライアントとサーバーの両方が安全であり、接続が安全である場合のみ、乱用を回避できます。
問題が悪用である場合は、単純な調整ソリューションで十分な場合があります。
クライアントにスヌーパーから隠されたコードがある場合、あなたが提案したように、ソルト、IPアドレス、時間ベースの値を使用し、それらを暗号化してからサーバー側で同じことを行うことはできませんか?これは基本的にmod_auth_tktが行うことであり、うまく機能します。それとも認証を構成しますか?
APIキーまたは何らかの形式の承認がなければ、不正なクライアントをサービスから遠ざけようとする敗北の戦いとなるでしょう。
あなたは複数のものを嗅ぐことができますが、難しい真実はほとんどが簡単に偽造されることです。
他のWebサービスを制御していますか?また、Webアプリ(http://example.com/
)はAPI(http://api.example.com/
)XHRまたはJSONPを介して、cURLなどのライブラリを使用してサーバー上のデータをプロキシし、データを取得して、サイトで利用できるようにすることができます。その後、必要に応じてアクセスを制御できます。