APIの不正使用を回避するにはどうすればよいですか？

「ウィジェット」、つまりパートナーがWebサイトに埋め込んで、UIを表示し、APIを呼び出すスクリプトを設計する必要があります。

基本的に、API呼び出しで提供するいくつかのIDに基づいて、これらのサイトのデータを表示します。回避したいのは、誰かがAPIを悪用し、それを使用してカタログ全体をこすり取ることです。

スクリプトを埋め込む各パートナーには、APIを呼び出すときに提供する必要がある公開鍵が与えられます。スクリプトをロードするときに、このキーを追加するように依頼することをお勧めします。例：

<script src="//initrode.com/widget/loader.js?key=xxxx"></script>

このようにして、スクリプトのリクエストを使用してキー/ソースIPペアを登録し、キー/ IPペアが登録されたものと一致する場合に限り、後続のAPI呼び出しに応答できます（ライフタイムが制限され、1日あたりのリクエスト数に制限があります）。

それは明らかに難読化によるセキュリティです（スクリプトを再読み込みすると完全にバイパスされます）。しかし、アクセスを制限する他の方法はありません。すべてのユーザーに一意のキーを提供することはできません。パートナーにのみ提供します。すべてのコードが誰でも利用できるようになるため、私は秘密鍵システムを使用できません。基本的に、パブリックAPIへのアクセスを制限しています。つまり、その定義が矛盾しています。

このソリューションについてどう思いますか、これらの制約をどうしますか？

いくつかのタイプの保護が必要です。

まず、サイトAのキーがサイトBで使用されないようにする必要があります。

理論的には、キーがドメインにバインドされている場合、refererヘッダーに依存することはできませんが、クライアントはスクリプトを直接埋め込んでいるため、クライアント側のに頼ることができdocument.locationます。その場所（またはその一部）をサーバーに直接送信することは信頼できません。ただし、これを使用してセッションキーを生成できます。

1. クライアントclient_keyはAPIライブラリのリクエストに埋め込みます。
2. サーバーは、APIにアクセスできるホストを判別します（ある場合）。
3. サーバーはセッションキーに「ソルト」を選択し、それをライブラリと共に（または別の事前認証交換の一部として）クライアントに送信します。
4. クライアントはsession_keyを使用して計算しhash(document.location.host + session_salt)ます。
5. クライアントはAPI呼び出しにsession_key+ client_keyを使用します。
6. サーバーclient_keyは、セッションののホストと「塩」を検索し、ハッシュを計算して、提供されたと比較することにより、呼び出しを検証しますclient_key。

次に、ハッカーハンクがデバッグコンソールを開いたり、サイトAで変更されたクライアントを使用してAPIで必要なことを実行できないようにする必要があります。

ただし、Hacker HankがAPIを悪用するのを完全に防ぐことは不可能ではないにしても非常に難しいことに注意してください。しかし、あなたはそれをより困難にすることができます。そして、私が知っているハンクを妨害する最も合理的な方法は、レート制限です。

• リクエスト/秒/セッションおよびリクエスト/時間/セッションの数を制限します。（アクティビティの急増はおそらく妥当ですが、単一のクライアントからの平均以上のトラフィックが持続することはありません。）
• セッション数/ IP /時間を制限します。
• リクエスト数/ IP /時間を制限します。スパイクを許可しますが、単一のIPからの大量のトラフィックを持続させません。

3番目に、すでに行っているように、トラフィックを暗号化します。確かに、NSAはそれを見るでしょう。しかし、ハッカーハンクはそうではありません。

JavaScriptファイルを保護されたリソースにして、ここで実行しているように聞こえます。そして、それをある種のトークン生成と同時にバンドルします。それは面白い。

私が一緒に働くセキュリティ担当者は、IPが偽造可能であるため、通常は手に負えないIPアドレスを無視します。しかし、SSLと組み合わせたIP制限を使用している場合、通常はそれでうまくいきます。

ただし、IPアドレスを「ホワイトリストに登録」する必要があります。そうしないと、ハッカーが玄関に入るだけです。

私は懐疑的でしたが、実際にはあなたの計画はかなりうまく機能していると思います。1）.jsファイルと後続のAPI呼び出しがTLS（SSLまたはhttps）で行われ、2）IPがホワイトリストに登録されている場合。次に、大胆な発言を行い、PCI（クレジットカード）のやり取りについても、セキュリティレビューに合格すると思います。

IMHO ...しかし、クレジットカード（PCI）や個人/個人情報（PII）ではなく、会社独自の情報を保護しようとしているだけの場合、SSLがなくても、これはおそらくどれだけ良いか、あなたのカタログを公開するリスクをいとわない。

または、このように表現します。SSLを使用すると、専用のハッカーはカタログを入手できません。（SSLを破る場合を除き、Amazonも破られる可能性があります）。SSLがなければ、専用のハッカーが通話を傍受し、IPを偽装し、カタログを引き落とす可能性があります。したがって、それはリスクを判断するようなものです。

IPホワイトリストを省く方法を考えようとしています。これは、本格的なOAuthを使用せずに、通常は管理するのが面倒だからです;）。その上で麺を作ります。