エンドユーザーがサイトに対して何らかの認証を行う必要がないため、それを認証方法として使用できず、他の介入なしにWebページでREST APIを使用できるようにする場合は、 RESTAPIを保護するための絶対確実な方法ではありません。認証されていないブラウザでデータが必要な場合は、誰でもそのデータを取得できます。
また、いつでもWebページを実行し、Webページからデータを解析できるため、このWebページを使用するために認証が必要ない場合、データはすでに一般に公開されていることにも注意してください。認証を必要とせずにそれを本当に保護することはできません。
絶対に確実なものはありませんが、RESTAPIの使用をより困難にするために試みることができることがいくつかあります。これらは単なる障害であり、セキュリティではありません。
有効期限が切れるトークンをWebページに配置し、それをWebリクエストに含めて、RESTAPIで有効期限が切れていないトークンであることを確認できます。これにより、誰かが別のブラウザページから直接REST APIを使用することはできなくなりますが(正当なトークンはありません)、サーバーが最初にホストページを取得し、トークンを取得して、それを使用してAPIにアクセスすることはできません。 。
リファラーをチェックして、ドメインからのWebリクエストのみを実行してみてください。リファラーがスプーフィングされる可能性があるため、これも絶対確実ではありませんが、障害になります。
返されるデータ(スクランブル、暗号化など)をどのように解釈するかがすぐにわからないように、データ応答を不明瞭にすることができます。繰り返しになりますが、これは、断固としたハッカーが独自のコードで応答を解釈する方法をリバースエンジニアリングすることを妨げる障害にすぎませんが、RESTAPIのカジュアルユーザーの邪魔になる作業はさらに多くなります。
多くのRESTAPIが行うことは、accessKey
すべてのAPI呼び出しで使用されます。WebページにはaccessKeyが組み込まれています。APIを(許可を得て)使用したい外部の開発者は、accessKeyを申請し、それを許可します(APIを使用できるようにする場合)。サーバーは、承認されたaccessKeyからのアクセス要求のみを許可します。accessKeyの不正使用があることがわかった場合は、サーバーでそのaccessKeyの使用をシャットダウンできます。自分のWebページのアクセスキーが誰かによってあなたの希望に反して使用されている場合は、自分のWebページに配置したaccessKeyを変更して、以前のaccessKeyの特権を取り消すことができます。明らかに、一部の不正な開発者は、自分のWebページからaccessKeyを取得し続ける可能性がありますが、APIを定期的に使用するには、定期的に取得する必要があります。繰り返しますが、それは
参考までに、別の同様の議論があります:JSONアクセスを制限する方法は?